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Spark 建立 在 抽象 的 RDD 之 上 ， 要 理解 Sparkk ， 就 需要 理解 RDD。 本 
书 详细 讲述 了 RDD 的 功能 及 内 部 实现 的 机 制 ， 通 过 前 析 源 代码 引导 读者 
深入 理解 Spark 集群 部 署 的 内 部 机 制 、Spark 内 部 调度 机 制 、Executor 的 内 
部 机 制 和 Shuffle 的 内 部 机 制 ， 进 而 讲述 了 “ 忽 丝 计划 ”的 内 部 机 制 。 本 
书 的 最 后 一 章 是 任何 Spark 应 用 者 都 非常 关注 的 Spark 性 能 调 优 内 容 。 通 
过 学 习 本 书 ， 可 以 使 读者 对 Spark 内 核 有 更 加 深入 的 理解 ， 从 而 实现 对 
Spark 系统 深度 调 优 、Spark 生产 环境 下 故障 的 定位 和 排除 ， 以 及 Spark 的 
二 次 开发 和 系统 高 级 运 维 。 

本 书 适合 于 对 大 数据 开发 有 兴趣 的 在 校 学 生 。 同 时 ， 对 于 有 分 布 式 计 
算 框 架 应 用 经 验 的 人 员 ， 本 书 也 可 以 作为 Spark 源 代码 解析 的 参考 书籍 。 
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起 源 于 美国 加 州 大 学 伯克利 分 校 AMP 实验 室 的 Spark 是 当今 大 数据 领域 最 活跃 、 最 热 
门 的 大 数据 计算 处 理 框 架 ，2009 年 Spark 诞生 于 AMP 实验 室 ，2010 年 Spark 正式 成 为 开源 
项 目 ，2013 年 Spark 成 为 Apache 基金 项 目 ，2014 年 Spark 成 为 Apache 基金 的 顶级 项 目 。 
Spark 成 功 构 建 了 一 体 化 、 多 元 化 的 大 数据 处 理 体 系 ， 成 功 使 用 Spark SQL、Spark Streaming、 
MLlib、GraphX 解决 了 大 数据 领域 的 Batch Processing 、Stream Processing 、Adhoc Query 等 核 
心 问 题 ，Spark SQL、Spark Streaming 、Mllib 、GraphX 四 个 子 框架 和 Spark 核心 库 之 间 互 相 共 
享 数据 及 相互 操作 ，Spark 生态 系统 强大 的 集成 能 力 是 其 他 大 数据 平台 无 可 匹敌 的 。 

本 书 主要 面向 的 对 象 是 广大 的 Spark 爱好 者 和 大 数据 开发 者 ， 以 Spark 内 核 解析 及 性 能 
调 优 为 主导 ， 由 浅 入 深 ， 对 Spark 内 核 运 行 机 制 从 源 代 码 角度 加 以 详细 人 解析， 全 书 共 分 9 
章 , 分别 是 ，RDD 的 功能 解析 、RDD 的 运行 机 制 、 部 署 模式 (Deploy) 解析 、Spark 调度 器 
(Scheduler) 运行 机 制 、 执 行 器 (Executor) 、Spark 的 存储 模块 (Storage) 、Shuffle 机 制 、 钨 
丝 计划 (Project Tungsten) 以 及 性 能 优化 。 读 者 通过 对 这 些 内 容 的 深入 学 习 ， 将 能 够 较为 透 
彻 地 掌握 Spark 这 一 大 数据 计算 框架 的 应 用 方法 。 

参与 本 书 编写 的 有 王家 林 、 段 知 华 、 张 敏 等 。 

在 本 书 阅读 过 程 中 ， 如 发 现任 何 纶 漏 或 有 任何 疑问 ， 可 以 加 入 本 书 的 阅读 群 (QQ: 
284078981) 提出 问题 , 会 有 专人 答疑 。 同时， 该 群 也 会 提供 本 书 所 用 案例 源 代码 。 
如 果 读 者 想 要 了 解 或 者 学 习 更 多 大 数据 相关 技术 ， 可 以 关注 DT 大 数据 梦 工 三 微 信 公众 
号 DT_Spark 及 QQ 群 284078981， 或 者 扫描 下 方 二 维 码 咨询 ， 也 可 以 通过 YY 客户 端 登录 
68917580 永久 频道 直接 体验 。 

王家 林 老 师 的 新 浪 微 博 是 http: //weibo. com/ilovepains/ ， 欢 迎 大 家 在 微 博 上 与 作者 进 
行 互动 。 

由 于 时 间 仓 促 ， 书 中 难免 存在 不 受 之 处 ， 请 读者 谅解 ， 并 提出 宝贵 意见 。 
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第 1 革 RDD 功能 解析 


Spark 建立 在 抽象 的 RDD (Resilient Distributed Datasets ， 弹 性 分 布 式 数据 集 ) 之 上 ,使 
得 它 可 以 用 一 致 的 方式 处 理 大 数据 不 同 的 应 用 场景 。Spark 把 所 有 需要 处 理 的 数据 转化 成 为 
RDD， 然 后 对 RDD 进行 一 系列 的 算 子 运算 ， 从 而 得 到 结果 。RDD 是 一 个 容错 的 、 并 行 的 数 
据 结 构 ， 它 可 以 将 数据 存储 到 内 存 和 磁盘 中 ， 并 能 控制 数据 分 区 ， 且 提供 了 丰富 的 API 来 操 
作 数 据 。Spark 一 体 化 多 元 化 的 解决 方案 极 大 地 减少 了 开发 和 维护 的 人 力 成 本 ， 以 及 部 署 平 
台 的 物力 成 本 ， 并 在 性 能 方面 有 极 大 的 优势 ， 特 别 适 合 于 迭代 计算 ， 如 机 器 学 习 和 图 计算 ; 
同时 Spark 对 Scala 和 Python 交互 式 Shell 的 支持 也 极 大 地 方便 了 通过 Shell 直接 使 用 Spark 集 
群 来 验证 解决 问题 的 方法 ， 这 对 于 原型 开发 至 关 重 要 ， 对 数据 分 析 人 员 有 着 无 法 抗拒 的 吸引 
力 。 本 章 将 详细 介绍 RDD 的 功能 。 




















由 RDD 产生 的 技术 背景 及 功能 


Hadoop 的 MapReduce 是 一 种 基于 数据 集 的 工作 模式 ， 这 种 模式 的 工作 方式 是 : 从 物理 
存储 上 加 载 数据 ， 然 后 操作 数据 ， 最 后 写 和 人 物理 存储 设备 。 

基于 数据 集 操 作 的 系统 对 两 种 应 用 的 处 理 并 不 高 效 : 一 是 迭代 式 的 算法 ,这 在 图 应 用 和 
机 器 学 习 领 域 很 常见 ， 二 是 交互 式 数据 挖掘 工具 (反复 查询 一 个 数据 子 集 )。 这 两 种 情况 
下 ， 将 数据 保存 在 内 存 中 能 够 极 大 地 提高 性 能 。 基 于 数据 集 的 方式 不 能 够 复 用 曾经 的 计算 结 
果 或 中 间 计 算 结 果 ，Hadoop 每 次 作业 都 从 磁盘 上 读 写 数据 ， 而 且 第 二 次 作业 运行 时 会 再 次 
从 磁盘 上 读 写 数据 ， 不 能 基于 内 存 共享 数据 ， 这 种 数据 集 系统 对 通用 的 应 用 的 操作 处 理 并 
不 高 效 ， 因 为 通用 的 处 理 一 般 都 是 用 和 迭 代 的 (如 机 可 学 习 和 图 计算 )， 男 外 假设 要 对 处 理 
的 结果 进行 复 用 的 话 ， 例 如 ， 想 要 复 用 图 1-1 中 Job#1 的 结果 ， 这 时 候 必须 在 磁盘 上 重 
读 ， 不 能 基于 内 存 复 用 ， 只 能 再 次 执行 Job#1 ， 不 会 从 内 存 中 复 用 上 次 的 结果 。 基 于 数据 
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图 1-1 工作 模型 图 
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集 的 系统 对 交互 式 数 据 挖 掘 工具 也 不 太 适 用 。 如 果 能 将 数据 保存 到 内 存 中 ， 其 性 能 将 会 
得 到 大 大 提升 。 

数据 集 的 特性 有 位 置 感知 、 容 错 性 和 负载 均衡 等 。 在 众多 特性 中 ， 最 难 实现 的 是 容错 
性 。 一 般 来 说 ， 分 布 式 数据 集 的 容错 性 有 两 种 方式 : 数据 检查 点 和 记录 数据 更 新 。 当 面向 大 
规模 数据 分 析 时 ， 数 据 检 查 点 操作 成 本 很 高 : 需要 通过 数据 中 心 的 网 络 链接 在 各 台 机 器 之 间 





复制 庞大 的 数据 集 ， 而 网 络 带宽 往往 比 内 存 带 宽 低 得 多 ， 同 时 还 需要 消耗 更 多 的 存储 资源 
(在 内 存 中 复制 可 以 减少 需要 缓存 的 数据 量 ， 而 存储 到 磁盘 则 会 拖 慢 应 用 程序 ) 。 

这 里 所 讲 的 RDD 就 是 在 这 种 背景 下 所 产生 的 。Spark 的 RDD 是 一 种 基于 工作 集 的 工作 
模式 。 无 论 数 据 集 还 是 工作 集 ， 它 们 都 有 一 些 共同 的 特征 ， 如 位 置 感知 、 容 错 和 负载 均衡 
等 ， 为 了 有 效 地 实现 容错 ，RDD 本 身 提 供 了 一 种 高 度 受 限 的 共享 内 存 模型 ， 它 是 只 读 的 记 
录 分 区 的 集合 ， 只 能 够 通过 从 外 界 读 取 文 件 ， 或 者 说 由 其 他 的 RDD 来 产生 。RDD 的 读 操 
作 可 以 精确 到 一 条 记录 ，RDD 的 写 操作 则 是 批量 的 。RDD 的 模型 特别 适合 迭代 ， 因 为 后 
面 的 RDD 都 是 依据 前 面 的 RDD 产生 的 ， 或 者 从 外 部 读 取 数 据 而 产生 的 ， 这 就 有 一 种 前 后 
的 依赖 关系 ， 创 建 RDD 的 一 系列 转换 被 记录 下 来 ( 即 Lineage 机 制 ) ， 以 便 恢 复 失去 的 
数据 。 

Spark 的 RDD 为 基于 工作 集 的 应 用 提供 了 更 为 通用 的 抽象 ， 用 户 可 以 对 中 间 结 果 进 行 显 
式 的 命名 和 物化 ， 控 制 其 分 区 ， 还 能 执行 用 户 选择 的 特定 操作 (而 不 是 在 运行 时 去 循环 执 
行 一 系列 MapReduce 步骤 ) ，Spark 为 工作 集 的 应 用 提供 了 基本 的 抽象 ， 同 时 又 具有 以 Ha- 
doop 为 代表 的 数据 流 模型 的 优势 (如 自动 位 置 的 感知 、 自 动容 错 、 伸 缩 性 和 良好 的 调度 
等 ) ，Spark 的 RDD 之 间 具 有 依赖 关系 且 高 度 抽象 ， 编 程 模型 更 容易 ， 容 错 更 好 。 一 些 算 
法 ， 如 逻辑 回归 、k 震 次 数列 等 ， 都 会 在 多 个 作业 中 重用 或 共用 计算 结果 ， 在 多 个 共享 数据 
集中 交互 式 查询 。RDD 本 身 采 用 分 布 式 内 存 计算 的 抽象 容错 机 制 解决 了 多 步骤 迭代 ， 在 一 
个 共享 数据 集中 执行 多 个 交互 式 查询 (多 个 Job 中 重用 计算 数据 ) ， 这 是 RDD 的 使 用 场景 。 
RDD 不 太 适 合 那些 异步 更 新 共享 状态 的 应 用 ， 如 并 行 Web 怜 虫 。RDD 的 目标 是 为 大 多 数 分 
析 型 应 用 提供 有 效 的 编程 模型 。 





























1 RDD 的 基本 概念 





RDD 的 定义 





RDD (Resilient Distributed Datasets ， 弹 性 分 布 式 数据 集 ) 是 分 布 式 内 存 的 一 个 抽象 概 
念 ， 是 一 种 高 度 受 限 的 共享 内 存 模型 ， 即 RDD 是 只 读 的 记录 分 区 的 集合 ， 能 横 跨 集群 的 所 
有 结 点 进行 并 行 计算 ， 是 一 种 基于 工作 集 的 应 用 抽象 。 

RDD 底层 存储 原理 为 : 其 数据 分 布 存 储 于 多 台 机 需 上 ， 事 实 上 ， 每 个 RDD 的 数据 都 以 
Block 的 形式 存储 在 多 台 机 器 上 。 图 1-2 所 示 是 Spark 的 RDD 存储 架构 图 ， 其 中 每 个 Executor 
会 启动 一 个 BlockManagerSlave， 并 管理 一 部 分 Block; 而 Block 的 元 数据 由 Driver 结 点 上 的 











BlockManagerMaster 保存 ， 
Block ，BlockManagerMaster 管理 RDD 与 Block 的 关系 ， 
BlockManagerSlave 发 送 指令 


驱动 器 
BlockManager 


删除 相应 的 Block。 
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BlockManagerSlave 生成 Block 后 向 BlockManagerMaster 注册 该 


当 RDD 不 再 需要 存储 时 ， 将 向 
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RDD 












BlockManagerMaster 


BlockManagerSlave 


BlockManagerSlave 


图 1-2 RDD 存储 架构 图 





管理 RDD 的 物理 分 区 ， 每 个 Block 就 是 结 点 上 对 应 的 一 个 数据 块 ， 可 以 存 


储 在 内 存 或 者 磁盘 上 。 而 RDD 中 的 Partition 是 一 个 逻辑 数据 块 ， 对 应 相应 的 物理 块 Block。 


本 质 上 ， 





一 个 RDD 在 代码 中 相当 于 是 数据 的 一 


个 元 数据 结构 ， 存 储 着 数据 分 区 及 其 逻辑 结 


构 的 映射 关系 ， 存 储 着 RDD 之 前 的 依赖 转换 关系 。 


在 此 需要 对 BlockManager 进 和 


18. 
19. 


BlockManagerMaster 会 持 有 整 





[水 洲 
人 
的 存储 变量 
* 如 memory .disk 和 off - heap 








* 请 注意 ， 
*/ 





private| spark | class BlockManager( 
executorld : String, 


rpcEnv: RpcEnyv, 


// 负 责 对 各 个 结 点 的 BlockManager 内 部 管理 的 数据 的 元 数据 进行 


val master: BlockManagerMaster, 
defaultSerializer : Serializer, 
val conf: SparkConf, 


memoryManager: MemoryManager, 


了 简要 的 解释 ，BlockManager 的 部 分 源 代码 如 下 。 


管理 Block( Driver 和 Executors) , 它 提供 一 个 接口 来 检索 本 地 和 远程 





在 使 用 BlockManager 之 前 必须 要 先 initialize( ) 


管理 与 维护 





mapOutputTracker: MapOutputTracker, 


shuffleManager: ShuffleManager, 


blockTransferService :BlockTransferService ， 


securityManager:SecurityManager， 


numUsableCores :Int) 


extendsBlockDataManager with Logging 


裕 个 Application 的 Block 的 位 置 、Block 所 占用 的 存储 空 
元 数据 信息 ， 在 Spark 的 Driver 的 DAGScheduler 中 就 是 通过 这 


间 等 
些 信息 来 确认 数据 运行 的 本 地 
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性 的 。Spark 支持 重 分 区 ， 数 据 通 过 Spark 默认 的 或 者 用 户 自 定义 的 分 区 器 来 决定 数据 块 分 
布 在 哪些 结 点 。RDD 的 物理 分 区 是 由 Block - Manager 管理 的 ， 每 个 Block 就 是 结 点 上 对 应 的 
一 个 数据 块 ， 可 以 存储 在 内 存 或 者 磁盘 中 。 而 RDD 中 的 Partition 是 一 个 逻辑 数据 块 ， 对 应 
相应 的 物理 块 Block。 本 质 上 ,一 个 RDD 在 代码 中 相当 于 是 数据 的 一 个 元 数据 结构 (一 个 
RDD 就 是 一 组 分 区 ) ， 存 储 着 数据 分 区 及 Block 、Node 等 的 映射 关系 以 及 其 他 元 数据 信息 ， 
存储 着 RDD 之 前 的 依赖 转换 关系 。 分 区 是 一 个 逻辑 概念 ，Transformation 前 后 的 新 旧 分 区 在 
物理 上 可 能 是 同一 块 内 存 存储 。 

Spark 通过 读 取 外 部 数据 创建 RDD， 或 通过 其 他 RDD 执行 确定 的 转换 Transformation 操 
作 (如 map、union 和 groubByKey) 而 创建 ， 从 而 构成 了 线性 依赖 关系 或 者 说 血统 关系 (lin- 
eage) ， 在 数据 分 片 丢失 时 可 以 从 依赖 关系 中 恢复 自己 独立 的 数据 分 片 ， 对 其 他 数据 分 片 或 
计算 机 没有 影响 ， 基 本 没有 检查 点 开销 ， 使 得 实现 容错 的 开销 很 低 ， 失 效 时 只 需要 重新 计算 
那些 RDD 分 区 ， 就 可 以 在 不 同 结 点 上 并 行 执行 ， 而 不 需要 回 滚 (Roll Back) 整个 程序 。 关 
于 落后 任务 ( 即 运行 很 慢 的 结 点 ) 是 通过 任务 备份 ， 重 新 调用 执行 进行 处 理 的 。 

因为 RDD 本 身 支 持 基 于 工作 集 的 运用 ， 所 以 可 以 使 Spark 的 RDD 持久 化 (Persist) 到 
内 存 中 ， 在 并 行 计 算 中 高 效 重 用 。 在 进行 多 个 查询 时 ， 就 可 以 显 性 地 将 工作 集中 的 数据 缓存 
到 内 存 中 ， 为 后 续 查 询 提供 复 用 ， 这 极 大 地 提升 了 查询 的 速度 。 在 Spark 中 ， 一 个 RDD 就 
是 一 个 分 布 式 对 象 集合 ， 每 个 RDD 可 分 为 多 个 片 (Partitions) ， 而 分 片 可 以 在 集群 环境 的 不 
同 结 点 上 计算 。 

RDD 作为 泛 型 的 抽象 的 数据 结构 (如 下 面 源 代码 的 第 8 行 代码 ) ， 文 持 两 种 计算 操作 算 
子 : Transformation (变换 ) 与 Action (行动 )。 并 且 RDD 的 写 操作 是 粗 粒 度 的 ， 读 操作 既 可 
是 粗 粒 度 的 也 可 以 是 细 粒 度 的 。 
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/** 每 个 RDD 都 有 5 个 主要 特性 * 
-分 区 列表 
-每 个 分 区 都 有 一 个 计算 函数 
-依赖 于 其 他 RDD 的 列表 
-数据 类 型 (Key - Value) 的 RDD 分 区 需 
-每 个 分 区 都 有 一 个 分 区 位 置 列 表 
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abstract class RDD[ T. ClassTag | ( 
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@ transient private var _sc:SparkContext, 
10. @ transient private vardeps:Seq[ Dependency[ _|| 
11. ) extendsSerializable with Logging 





在 此 需要 对 SparkContext 做 出 解释 : SparkContext 是 Spark 功能 的 主要 入 口 点 , 一 个 
SparkContext 代表 一 个 集群 连接 ， 可 以 用 其 在 集群 中 创建 RDD 、 累 加 变量 和 广播 变量 等 ， 在 
每 一 个 可 用 的 JVM 中 只 有 一 个 SparkContext， 在 创建 一 个 新 的 SparkContext 之 前 必须 先 停止 
该 JVM 中 可 用 的 SparkContext， 这 种 限制 可 能 最 终 会 被 修改 。SparkContext 被 实例 化 时 需要 
一 个 SparkConf 对 象 去 描述 应 用 的 配置 信息 ， 在 这 个 配置 对 象 中 设置 的 信息 会 覆盖 系统 默认 
的 配置 。 
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RDD 五 大 特性 


1. 分 区 列表 (a list of partitions ) 











Spark RDD 是 被 分 区 的 ， 每 一 个 分 区 都 会 被 一 个 计算 任务 (Task) 处 理 ， 分 区 数 决定 了 
并 行 计 算 的 数量 ，RDD 的 并 行 度 默认 从 父 RDD 传 给 子 RDD。 默 认 情 况 下 ,一 个 HDFS 上 的 
数据 分 片 就 是 一 个 partiton ，RDD 分 片 数 决定 了 并 行 计 算 的 力度 ， 可 以 在 创建 RDD 时 指定 
RDD 分 片 个 数 ， 如 果 不 指 定 分 区 数量 ， 当 RDD 从 集合 创建 时 ， 则 默认 分 区 数量 为 该 程序 所 
分 配 到 的 资源 的 CPU 核 数 (每 个 Core 可 以 承载 2 ~ 4 个 partition) ， 如 果 是 从 HDFS 文件 创 
建 ， 默 认为 文件 的 Block 数 。 

2. 每 一 个 分 区 都 有 一 个 计算 函数 (a function for computing each split ) 

每 个 分 区 都 会 有 计算 函数 ，Spark 的 RDD 的 计算 函数 是 以 分 片 为 基本 单位 的 ， 每 个 
RDD 都 会 实现 compute 函数 ， 对 具体 的 分 片 进行 计算 ，RDD 中 的 分 片 是 并 行 的 ， 所 以 是 分 
布 式 并 行 计 算 ， 有 一 点 非常 重要 ， 就 是 由 于 RDD 有 前 后 依赖 关系 ， 遇 到 宽 依 赖 关 系 ， 如 
reduceByKey 等 这 些 操作 时 划分 成 Stage ，Stage 内 部 的 操作 都 是 通过 Pipeline 进行 的 ， 在 具体 
处 理 数据 时 它 会 通过 BlockManager 来 获取 相关 的 数据 ， 因 为 具体 的 split 要 从 外 界 读数 据 ， 
也 要 把 具体 的 计算 结果 写 和 外界， 所 以 用 了 一 个 管理 器 ， 具 体 的 split 都 会 映射 成 Block- 
Manager 的 Block ， 而 具体 的 split 会 被 函数 处 理 ， 也 数 处 理 的 具体 形式 是 以 任务 的 形式 进 
行 的 。 

3. 依赖 于 其 他 RDD 的 列表 (a list of dependencies on other RDDs) 

由 于 RDD 每 次 转换 都 会 生成 新 的 RDD， 所 以 RDD 会 形成 类 似 流水 线 一 样 的 前 后 依赖 
关系 ， 当 然 宽 依赖 就 不 类 似 于 流水 线 了 ， 宽 依赖 后 面 的 RDD 具体 的 数据 分 片 会 依赖 前 面 
所 有 的 RDD 的 所 有 数据 分 片 ， 这 个 时 候 数据 分 片 就 不 进行 内 存 中 的 Pipeline， 一 般 都 是 跨 
机 器 的 ， 因 为 有 前 后 的 依赖 关系 ， 所 以 当 有 分 区 的 数据 丢失 时 ，Spark 会 通过 依赖 关系 进行 
重新 计算 ， 从 而 计算 出 丢失 的 数据 ， 而 不 是 对 RDD 所 有 的 分 区 进行 重新 计算 。RDD 之 间 的 
依赖 有 两 种 : 窄 依赖 (Narrow Dependency) 和 宽 依 赖 (Wide Dependency) 。RDD 是 Spark 的 
核心 数据 结构 ， 通 过 RDD 的 依赖 关系 形成 调度 关系 。 通 过 对 RDD 的 操作 形成 整个 Spark 
程序 。 

RDD 有 窗 依 赖 和 宽 依 赖 两 种 不 同类 型 的 依赖 ， 其 中 的 窗 依 赖 指 的 是 每 一 个 parent RDD 
的 Partition 最 多 被 child RDD 的 一 个 Partition 所 使 用 ， 而 宽 依 赖 指 的 是 多 个 child RDD 的 Par- 
tition 会 依赖 于 同一 个 parent RDD 的 Partition。 可 以 从 两 个 方面 来 理解 RDD 之 间 的 依赖 关系 ， 
一 方面 是 RDD 的 parent RDD 是 什么 ， 另 一 方面 是 依赖 于 parent RDD 的 哪些 Partion; 根据 依 
赖 于 parent RDD 的 哪些 Partion 的 不 同情 况 ，Spark 将 Dependency 分 为 宽 依 赖 和 罕 依 赖 两 种 。 
Spark 中 的 宽 依 赖 指 的 是 生成 的 RDD 的 每 一 个 partition 都 依赖 于 父 RDD 所 有 的 partition ， 
宽 依赖 典型 的 操作 有 groupByKey 、sortByKey 等 ， 宽 依赖 意味 着 Shuffle 操作 ， 这 是 Spark 
划分 Stage 的 边界 的 依据 ，Spark 中 的 宽 依 赖 支 持 两 种 Shuffle Manager， 即 HashShuffleMan- 
ager 和 SortShuffleManager， 前 者 是 基于 Hash 的 Shuffle 机 制 ， 后 者 是 基于 排序 的 Shuffle 
机 制 。 











































































































































































内 核 机 制 解析 及 性 能 调 优 


4. key - value 数据 类 型 的 RDD 分 区 器 (a Partitioner for key - value RDDS) 、 控 制 分 
区 策略 和 分 区 数 

每 个 key - value 形式 的 RDD 都 有 Partitoner 属性 ， 它 决定 了 RDD 如 何 分 区 。 当 然 ，Par- 
titon 的 个 数 还 决定 了 每 个 Stage 的 Task 个 数 。RDD 的 分 片 函 数 可 以 分 区 (Partitioner) ， 可 传 




















入 相关 的 参数 ， 如 HashPartitioner 和 RangePartitioner， 它 本 身 针对 key - value 的 形式 ， 如 果 
不 是 key - value 的 形式 它 就 不 会 有 具体 的 Partitioner，Partitioner 本 身 决定 了 下 一 步 会 产生 多 
少 并 行 的 分 片 ， 同 时 它 本 身 也 决定 了 当前 并 行 (Parallelize) Shuflle 输出 的 并 行 数据 ， 从 而 
使 Spark 具有 能 够 控制 数据 在 不 同 结 点 上 分 区 的 特性 ， 用 户 可 以 自 定义 分 区 策略 ， 如 Hash 
分 区 等 。Spark 提供 了 partitionBy 运算 符 ， 能 通过 集群 对 RDD 进行 数据 再 分 配 来 创建 一 个 新 
的 RDD。 

5. 每 个 分 区 都 有 一 个 优先 位 置 列表 (a list of preferred locations to compute each 
split on ) 

优先 位 置 列表 会 存储 每 个 Partition 的 优先 位 置 ， 对 于 一 个 HDFS 文件 来 说 ， 就 是 每 个 
Partition 块 的 位 置 。 观 察 运 行 Spark 集群 的 控制 台 就 会 发 现 ，Spark 在 具体 计算 、 具 体 分 片 以 
前 ， 它 已 经 清楚 地 知道 任务 发 生 在 哪个 结 点 上 ， 也 就 是 说 任务 本 身 是 计算 层面 的 、 代 码 层面 
的 ， 代 码 发 生 运算 之 前 它 就 已 经 知道 它 要 运算 的 数据 在 什么 地 方 ， 有 具体 结 点 的 信息 。 这 就 
符合 大 数据 中 数据 不 动 代码 动 的 原则 。 数 据 不 动 代码 动 的 最 高 境界 是 数据 就 在 当前 结 点 的 内 
存 中 。 这 时 候 有 可 能 是 Memory 级 别 或 Tachyon 级 别 的 ，Spark 本 身 在 进行 任务 调度 时 会 尽 可 
能 地 将 任务 分 配 到 处 理 数据 的 数据 块 所 在 的 具体 位 置 。 据 Spark 的 RDD. Scala 源 代码 函数 
getParferredLocations 可 知 ， 每 次 计算 都 符合 完美 的 数据 本 地 性 。 

可 在 RDD 类 源 代码 文件 中 找到 4 个 方法 和 1 个 属性 ， 对 应 上 述 所 阐述 的 RDD 的 五 大 特 
性 ， 源 代码 剪辑 如 下 。 









































/*#* 返回 一 个 RDD 分 区 列表 ,这 个 方法 仅 被 调用 一 次 , 它 是 安全 地 执行 一 次 耗 时 计算 * 7 
protected def getPartitions : Array| Partition ] 
/** 通过 子 类 来 实现 给 定 分 区 的 计算 * / 
@ DeveloperApi 
def compute( split: Partition, context: TaskContext ) : Iterator[ T | 
/** 返回 对 父 RDD 的 依赖 列表 ,这 个 方法 仅 被 调用 一 次 , 它 是 安全 地 执行 一 次 耗 时 计算 * / 
protected defgetDependencies:Seq[ Dependency[ _| ] = deps 
/*#* 可 选 的 ,分 区 的 方法 ,可 指定 如 何 分 区 */ 
@ transient val partitioner: Option|[ Partitioner | = None 
10. /** 可 选 的 ,指定 优先 位 置 ,输入 参数 是 split 分 片 ,输出 结果 是 一 组 优先 的 结 点 位 置 */ 
11. protected def getPreferredLocations( split: Partition) :Seq| String] = Nil 





0 





在 此 需要 对 TaskContext、Partitioner 和 Partition 等 概念 做 出 解释 ，TaskContext 是 读 取 或 
改变 执行 任务 的 环境 ， 用 org. apache. spark. TaskContext get( ) 可 返回 当前 可 用 的 TaskContext， 
可 以 调用 内 部 的 函数 访问 正在 运行 任务 的 环境 信息 。Partitioner 是 一 个 对 象 ， 定义 了 如 何在 
key - value 类 型 的 RDD 的 元 素 中 用 key 分 区 ， 从 0 到 numPartitions -1 区 间 内 映射 每 一 个 key 
到 partition ID。Partition 是 在 一 个 RDD 的 分 区 标识 符 ， 源 代码 如 下 。 
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1. trait Partition extendsSerializable | 

2 // 在 它 的 父 RDD 的 分 区 索引 

3 def index :Int 

4 /最 好 默认 实现 HashCode > 
5 override defhashCode( ) :Int = index 

Go 





| RDD 弹性 特性 的 7 个 方面 

RDD 作为 弹性 分 布 式 数据 集 ， 它 的 弹性 具体 体现 在 以 下 7 个 方面 。 

1. 自动 进行 内 存 和 磁盘 数据 存储 的 切换 

Spark 会 优先 把 数据 放 到 内 存 中 ， 如 果 内 存 实在 放 不 下 ， 则 会 放 到 磁盘 里 面 ， 不 但 能 计 
算 内 存放 下 的 数据 ， 也 能 计算 内 存放 不 下 的 数据 。 如 果实 际 数据 大 于 内 存 ， 则 要 考虑 数据 放 
置 策略 和 优化 算法 。 当 应 用 程序 内 存 不 足 时 ，Spark 应 用 程序 将 数据 自动 从 内 存 存储 切换 到 
磁盘 存储 ， 以 保障 其 高 效 运行 。 

2. 基于 Lineage ( 血统 ) 的 高 效 容错 机 制 

Lineage 是 基于 Spark RDD 的 依赖 关系 来 完成 的 〈 依 赖 分 为 窄 依赖 和 宽 依 赖 两 种 形态 ) ， 
这 种 前 后 的 依赖 关系 可 恢复 失去 的 数据 。 每 个 操作 只 关联 其 父 操作 ， 各 个 分 片 的 数据 之 间 互 
影响 ， 出 现 错误 时 只 需 恢 复 单个 Split 的 特定 部 分 即 可 。 常 规 容错 有 两 种 方式 : 一 个 是 数 
据 检查 点 ， 男 一 个 是 记录 数据 的 更 新 。 数 据 检 查 点 的 基本 工作 方式 就 是 通过 数据 中 心 的 网 络 
链接 不 同 的 机 器 ， 然 后 每 次 操作 时 都 要 复制 数据 集 ， 就 相当 于 每 次 都 有 一 个 拷贝 ,拷贝 是 要 
通过 网 络 的 ， 网 络 带 宽 就 是 分 布 式 的 瓶 虎 ， 对 存储 资源 也 是 很 大 的 消耗 。 记 录 数 据 更 新 就 是 
每 次 数据 变化 了 就 记录 一 下 ， 这 种 方式 不 需要 重新 复制 一 份 数据 ,但 是 比较 复杂 ， 会 消耗 性 
能 。Spark 的 RDD 通过 记录 数据 更 新 的 方式 很 高 效 ， 原 因为 : 一 是 RDD 是 不 可 变 的 且 是 Lazy 
级 别 ; 二 是 RDD 的 写 操作 是 粗 粒 度 的 。 但 是 RDD 的 读 操 作 既 可 以 是 粗 粒度 的 也 可 以 是 细 粒 
度 的 。 

3. Task 如 果 失 败 会 自动 进行 特定 次 数 的 重 试 
默认 重 试 次 数 为 4 次 。 源 代码 如 下 。 








































































































private| spark | class TaskSchedulerImpl( 
val sc:SparkContext, 
valmaxTaskFailures : Int, 
isLocal : Boolean = false) 
extends TaskScheduler with Logging /继承 任务 调度 器 .日志 trait 
| 


def this( sc:SparkContext) = this( se, sc. conf getInt( " spark. task. maxFailures" ,4) ) 





Se SN 
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TaskSchedulerImpl 是 底层 的 任务 调度 接口 TaskScheduler 的 实现 ， 这 些 Schedulers 从 每 一 
个 Stage 中 的 DAGScheduler 中 获取 TaskSet， 运 行 它 们 。DAGScheduler 是 高 层 调 度 ， 它 计算 
每 个 Job 的 Stages 的 DAG， 然 后 提交 给 Stages， 用 TaskSets 的 形式 启动 底层 TaskScheduler 调 
度 在 集群 中 运行 。 

4. Stage 如 果 失 败 会 自动 进 特定 次 数 的 重 试 

这 样 Stage 对 象 可 以 跟踪 多 个 StageInfo (存储 SparkListeners 监听 到 的 Stage 信息 ， 将 
Stage 信息 传递 给 Listeners 或 web UI。 默 认 重 试 次 数 为 4 次 ， 且 可 以 直接 运行 计算 失败 的 阶 
段 ， 只 计算 失败 的 数据 分 片 ，Stage 源 代 码 如 下 。 

















private| scheduler | abstract class Stage( 
val id: Int, 
val rdd: RDD| _|],， 


val numTasks: Int, 


1 

2 

3 

4 

5, val parents :List[ Stage ] ， 
0 val firstJobId : Int, 

val callSite: CallSite ) 

8 extends Logging | 

9 //Partition 的 个 数 

10. val numPartitions = rdd. partitions. length 

11. // 属 于 这 个 工作 集 的 Stage 

[2 val joblds = new HashSetl Int | 

13. val pendingPartitions = new HashSet|[ Int | 

14. ”// 用 于 此 Stage 的 下 一 个 新 Attempt 的 标识 了 D 


ss private var nextAttemptld:Int =0 








16. val name: String = callSite. shortForm 


[3k val details: String = callSite. longForm 


18. private var _internalAccumulators: Seq[ Accumulator[ Long | ] = Seq. empty 
19. ”Stage 内 部 所 有 任务 共享 的 累加 器 

20. def internalAccumulators: Seq[ Accumulator[ Long | ] = _internal Accumulators 
2 /六 六 


2 * 重新 初始 化 与 该 Stage 相关 联 的 内 部 累加 器 
28 * 当 属 于 这 个 Stage 的 任务 的 一 个 子 集 已 经 完成 时 , 称 为 一 次 提交 ,否则 
24. * 重新 初始 化 内 部 累加 天 , 这 里 又 将 覆盖 部 分 任务 





2 7 

26. def resetInternalAccumulators( ) :Unit = | 

2 _internalAccumulators = Internal Accumulator. create( rdd. sparkContext ) 
28. 

2 /六 术 


30.，* 最 新 的 [ StagelInfo] object 指针 。 这 需要 在 这 里 被 初始 化 ， 
31. * 任何 Attempts 都 是 被 创造 出 来 的 ,因为 DAGScheduler 使 用 StagelInfo 
3 站 * 告诉 SparkListeners 工作 开始 时 ( 即 发 生 之 前 的 任何 阶段 已 经 创建 ) 
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洲 / 

private var _latestInfo :StageInfo = StageInfo. fromStage( this, nextAttemptld ) 

[沙洲 
* 设置 Stage Attempt IDs, 当 失败 时 可 以 读 取 失 败 信息 ， OO 
* 跟踪 这 些 失 败 ,为 了 避免 无 休止 的 重复 不 断 失败 
* 在 同一 个 Stage 中 多 个 Tasks 任务 尝试 失败 时 ,我们 使 用 Hashset 集合 记录 每 一 个 
* 尝试 失败 的 ID 号 ,这 样 可 避免 记录 重复 的 失败 情况 ( spark -5945 ) 
*/ 

private val fetchFailedAttemptlds = new HashSet[ Int | 



































private[ scheduler | def clearFailures( ) :Unit = | 
fetchFailedAttemptlds. clear( ) 
| 
[沙洲 
* 检查 是 否 应 该 中 止 由 于 连续 多 次 读 取 失 败 的 Stage 
* 如 果 失 败 的 次 数 超过 允许 的 次 数 ,此 方法 更 新 失败 Stage Attempts 和 返回 的 运行 集 
*/ 
privatel| scheduler | def failedOnFetchAndShouldAbort( stageAttemptId :Int) :Boolean = | 
fetchFailedAttemptlds. add ( stageAttemptld ) 
fetchFailedAttemptlds. size >= Stage. MAX_CONSECUTIVE_FETCH_FAILURES 
| 
/** 在 Stage 中 创建 一 个 新 的 attempt */ 
def makeNewStageAttempt( 

















numPartitionsToCompute :Int ， 
taskLocalityPreferences :Seq[ Seql TaskLocation | | = Seq. empty) :Unit = | 
_latestInfo = StageInfo. fromStage( 
this ,nextAttemptId ,Some( numPartitionsToCompute ) ,taskLocalityPreferences ) 
nextAttemptld + =1 
| 
/*#* 返回 当前 Stage 中 最 新 的 Stagelnfo */ 
def latestInfo :StageInfo = _latestInfo 
override final defhashCode( ) :Int =id 


override final def equals( other:Any) :Boolean = other match | 





case stage:Stage => stage !=null && stage. id == id 
case _ => false 
| 
// 返 回 需要 重新 计算 的 分 区 标识 的 序列 
def findMissingPartitions( ) :Seq| Int] 
| 
private[ scheduler | object Stage | 
// 允许 在 一 个 Stage 的 中 止 的 连续 故障 数 
val MAX_CONSECUTIVE_FETCH_FAILURES =4 
| 
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Stage 是 Spark Job 运行 时 具有 相同 逻辑 功能 且 并 行 计算 任务 的 一 个 基本 单元 。Stage 中 
所 有 的 任务 都 依赖 同样 的 Shuffle， 每 个 DAG 任务 通过 DAGScheduler 在 Stage 的 边界 处 发 
生 Shuffle 形成 Sage， 然 后 DAGScheduler 运行 这 些 阶段 的 拓扑 顺序 。 每 一 个 Stage 都 可 能 
是 ShuffleMapStage， 如 果 是 ShuffleMapStage 则 跟踪 每 个 输出 结 点 (nodes) 上 的 输出 文件 分 
区 ， 它 的 任务 结果 是 输入 其 他 的 Stage， 或 者 输入 一 个 ResultStage， 若 输入 一 个 Result- 
Stage， 这 个 ResultStage 的 任务 直接 在 这 个 RDD 上 运行 计算 这 个 Spark Action 的 函数 (如 
count( ) 、save() 等 ) ， 并 生成 shuffleDep 等 字段 描述 Stage 和 生成 变量 (如 outputLocs 和 
numAvailableOutputs) ， 为 跟踪 map 输出 做 准备 。 每 一 个 Stage 都 会 有 firstjobid， 确 定 第 一 
个 提交 Stage 的 Jp ， 当 使 用 FIFO 调度 时 ， 会 使 得 其 前 面 的 Job 先行 计算 或 快速 恢复 ( 失 
败 时 ) 。 

在 此 需要 对 ShuffleMapStage 、ResultStage 和 SparkListener 等 做 出 解释 。ShuffleMapStage 
是 DAG 产生 数据 进行 Shuffle 的 中 间 阶 段 ， 它 发 生 在 每 次 Shuffle 操作 之 前 ， 可 能 包含 多 个 
pipelined 操作 ，ResultStage 阶段 捕获 函数 在 RDD 的 分 区 上 进行 Action 算 子 计算 结果 ， 有 些 
Stages 并 不 是 运行 在 RDD 的 所 有 分 区 上 如 first( ) 、lookup ( ) 等 。 SparkListener 是 Spark 调 
度 右 的 事件 监听 接口 ， 注 意 这 个 接口 随 着 Spark 的 版 本 的 不 同 会 跟随 着 变化 。 

5. Checkpoint 和 Persist (检查 点 ,持久 化 ) ， 可 主动 或 被 动 触 发 

Checkpoint 是 对 RDD 进行 的 标记 ， 会 产生 一 系列 的 文件 ， 且 所 有 父 依 赖 都 会 被 Remove， 
是 整个 依赖 (Lineage) 的 终点 。Checkpoint 也 是 Lazy 级 别 的 。persist 后 RDD 工作 时 ， 每 一 
个 工作 结 点 都 会 把 计算 的 分 片 结果 保存 在 内 存 或 磁盘 中 ， 下 一 次 如 果 要 对 相同 的 RDD 进行 
其 他 的 Action 计算 ， 就 可 以 重用 。 

因为 用 户 只 与 Driver Program 交互 ， 因 此 只 能 用 RDD 中 的 cache( ) 方 法 去 cache 用 户 能 
看 到 的 RDD。 所 谓 能 看 到 ， 是 指 经 过 Transformation 算 子 处 理 后 生成 的 RDD， 而 某 些 在 
Transformation 算 子 中 Spark 自己 生成 的 RDD 是 不 能 被 用 户 直接 cache 的 ， 如 reduceByKey( ) 
中 生成 的 ShuffleRDD 、MapPartitionsRDD 是 不 能 被 用 户 直接 cache 的 。 在 Driver Program 中 设 
定 RDD. cache( ) 后 ， 系 统 如 何 对 进行 cache? 首先 在 计算 RDD 的 Partition 之 前 就 去 判断 Par- 
tition 要 不 要 被 cache ， 如 果 要 被 cache 的 话 ， 先 将 Partition 计算 出 来 ,然后 cache 到 内 存 。 
Cache 只 使 用 memory， 写 到 磁盘 的 话 就 checkpoint。 调 用 RDD. cache( ) 后 ，RDD 就 变 成 per- 
sistRDD 了 ， 其 StorageLevel 为 MEMORY_ONLY，PpersistRDD 会 告知 Driver 说 自己 是 需要 被 
persist 的 。 此 时 会 调用 RDD. iterator( ) ，RDD 的 iterator( ) 的 源 代 码 如 下 。 





































































































[沙洲 
* RDD 的 内 部 方法 ,将 从 合适 的 缓存 中 读 取 ,否则 计算 它 
* 这 不 应 该 被 用 户 直 接 使 用 ,但 可 用 于 实现 自 定义 的 子 RDD 
*/ 
final def iterator( split: Partition, context:TaskContext) :Iterator[| T | = | 
这 (storageLevel ! = StorageLevel. NONE) 1// 存 储 级 别 不 等 于 NONE 


getOrCompute( split ,context ) 



































| else | 


SF ee RA A ne 


computeOrReadCheckpoint( split ,context ) 
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当 RDD. iterator( ) 被 调用 时 ， 也 就 是 要 计算 该 RDD 中 的 某 个 Partition 时 ， 会 先 去 cache- 
Manager 中 获取 一 个 blockId， 然 后 去 BlockManager 中 匹配 该 Partition 是 否 被 checkpoint， 如 果 
是 就 不 用 计算 该 Partiton 了， 直接 从 checkpoint 中 读 取 该 Partition 的 所 有 records 放 入 Array- 
Buffer 里 面 ， 如 果 没 有 被 checkpoint 过 ， 则 先 将 Partiton 计算 出 来 ， 然 后 将 其 所 有 的 records 
放 到 cache 中 。 总 体 来 说 当 RDD 会 被 重复 使 用 (不 能 太 大 ) 时 ，RDD 需要 cache。Spark 自 
动 监控 每 个 结 点 缓存 的 使 用 情况 ,利用 最 近 最 少 使 用 的 原则 来 删除 老 旧 的 数据 。 如 果 想 手动 
删除 RDD， 可 以 使 用 RDD. unpersist( ) 方 法 。 

此 外 ， 可 以 利用 不 同 的 存储 级 别 存储 每 一 个 被 持久 化 的 RDD。 例 如 ， 它 允许 持久 化 集 
合 到 磁盘 上 、 将 集合 作为 序列 化 的 Java 对 象 持久 化 到 内 存 中 、 在 结 点 间 复 制 结合 或 者 存储 
集合 到 Tachyon 中 。 可 以 通过 传递 一 个 StorageLevel 对 象 给 persist( ) 方 法 设置 这 些 存储 级 别 。 
cache( ) 方 法 使 用 默认 的 存储 级 别 - StorageLevel. MEMORY_ONLY。RDD 根据 useDisk 、use- 
Memory 、useOffHeap 、deserialized 和 replication 这 5 个 参数 的 组 合 提供 了 常用 的 12 种 存储 级 
别 ， 完 整 的 存储 级 别 介绍 如 下 。 



























































val NONE = newStorageLevel( false ,false ,false ,false) 

val DISK_ONLY = newStorageLevel(true ,false ,false,false) 

val DISK_ONLY_2 = newStorageLevel( true ,false ,false ,false,2) 

val MEMORY_ONLY = newStorageLevel( false ,true , false , true ) 

val MEMORY_ONLY_2 = newStorageLevel( false ,true ,false , true ,2) 

val MEMORY_ONLY_SER = newStorageLevel( false ,true , false , false ) 

val MEMORY_ONLY_SER_2 = newStorageLevel( false ,true ,false , false ,2) 
val MEMORY_AND_DISK = newStorageLevel( true, true , false , true ) 

val MEMORY_AND_DISK_2 = newStorageLevel( true ,true ,false ,true ,2 ) 
val MEMORY_AND_DISK_SER = newStorageLevel( true ,true , false , false ) 
. val MEMORY_AND_DISK_SER 2 = newStorageLevel( true ,true ,false ,false ,2) 
// 堆 外 存储 

13. val OFF_HEAP = newStorageLevel( false,false,true ,false) 
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在 此 需要 对 StorageLevel 做 出 相应 的 解释 。StorageLevel 是 控制 存储 RDD 的 标志 ， 每 个 
StorageLevel 记录 RDD 是 否 使 用 Memory ， 或 使 用 ExternalBlockStore 存储 ， 如 果 RDD 脱离 了 
Memory 或 ExternalBlockStore， 是 否 drop 掉 RDD， 是 否 保 留 数据 在 内 存 中 的 序列 化 格式 ， 以 
及 是 否 复制 多 个 结 点 的 RDD 分 区 。 男 外 ，org. apache. spark. storage. StorageLevel 是 单 实 例 
(singleton) 对 象 ， 包含 了 一 些 静 态 常量 和 常用 的 存储 级 别 ， 且 可 用 单 实例 对 象 工厂 方法 
(StorageLevel (…) ) 创建 定制 化 的 存储 级 别 。 

Spark 的 多 个 存储 级 别 意味 着 在 内 存 利 用 率 和 CPU 利用 率 间 的 不 同 权衡 。 推 荐 通过 下 面 
的 过 程 选择 一 个 合适 的 存储 级 别 . 外 如果 RDD 适合 默认 的 存储 级 别 ( MEMORY_ONLY)， 
就 选择 默认 的 存储 级 别 。 因 为 这 是 CPU 利用 率 最 高 的 选项 ,会 使 RDD 上 的 操作 尽 可 能 地 
快 。@ 如 果 不 适 合用 默认 级 别 ， 选 择 MEMORY_ONLY_SER。 选 择 一 个 更 快 的 序列 化 库 来 提 
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高 对 象 的 空间 使 用 率 ， 但 是 仍 能 够 相当 快 地 访问 。 凶 除非 算 子 计算 RDD 花费 较 大 或 者 需要 
过 滤 大 量 的 数据 ， 否 则 不 要 将 RDD 存储 到 磁盘 上 ， 和 否则 重复 计算 一 个 分 区 就 会 和 从 磁盘 上 
读 取 数据 一 样 慢 。 如 果 希 望 更 快 地 恢复 错误 ， 可 以 利用 replicated 存储 级 别 ， 所 有 的 存储 

















级 别 都 可 以 通过 replicated 计算 丢失 的 数据 来 文 持 完整 的 容错 ， 另 外 replicated 的 数据 能 在 
RDD 上 继续 运行 任务 ， 而 无 须 重 复 计算 丢失 的 数据 。 在 拥有 大 量 内 存 的 环境 中 或 者 多 应 用 
程序 的 环境 中 ，OFF_HEAP 将 对 象 从 堆 中 脱离 出 来 序列 化 ， 然 后 存储 在 一 大 块 内 存 中 ， 这 
就 像 它 存储 在 磁盘 上 一 样 ， 但 它 仍 在 RAM 中 。 对 象 在 这 种 状态 下 不 能 直接 使 用 ， 它 们 必须 
首先 反 序列 化 ， 也 不 受 垃 圾 收集 机 制 影响 。OFF_HEAP 具有 如 下 优势 : OFF_HEAP 运行 多 
个 执行 者 共享 的 Tachyon 中 相同 的 内 存 池 ; OPP_HEAP 显著 地 减少 来 自 GC 回收 的 划分 ;如 
果 单 个 的 Executor 崩溃 ， 缓 存 的 数据 不 会 丢失 。 

6. 数据 调度 弹性 (DAGScheduler、TASKScheduler 和 资源 管理 无 关 ) 

Spark 将 执行 模型 抽象 为 通用 的 有 向 无 环 图 计划 (DAG) ， 这 可 以 将 多 Stage 的 任务 串联 
或 并 行 执行 ， 从 而 无 须 将 Stage 的 中 间 结 果 输 出 到 HDFS 中 ， 当 发 生 运 行 结 点 故障 时 可 有 其 
他 可 用 结 点 代替 该 故障 结 点 运行 。 

7. 数据 分 片 的 高 度 弹性 ( coalesce) 

Spark 进行 数据 分 片 时 ， 默 认 将 数据 放 在 内 存 中 ， 如 果 内 存放 不 下 ， 一 部 分 会 放 在 磁盘 
上 进行 保存 。coalesce 的 源 代码 如 下 。 



































和 
2. * 返回 一 个 新 的 RDD ,恰好 有 numpartitions 分 区 ,类 似 的 合并 定义 在 RDD 序列 
3. * 此 操作 的 结果 在 一 个 窄 依 赖 ,如 果 是 从 1000 个 分 区 到 100 个 分 区 ,就 

4. *# 不 会 有 一 个 Shuffle, 而 不 是 每 100 个 新 的 分 区 将 要 求 10 个 当前 分 区 

有 
6 
7 
8 
9 














case class Coalesce( numPartitions: Int ,child :SparkPlan ) extends UnaryNode | 
override def output:Seq| Attribute | = child. output 
override def outputPartitioning: Partitioning = | 


if( numPartitions == 1 ) SinglePartition 


10. else UnknownPartitioning( numPartitions ) 

Te 

2 protected override def doExecute( ) :RDD[ InternalRow | = | 
13. child. execute( ). coalesce( numPartitions ,shuffle = false ) 
14. | 

15. override def canProcessUnsafeRows : Boolean = true 

16. | 


例如 ， 在 计算 的 过 程 中 会 产生 很 多 的 数据 碎片 ， 此 时 产生 一 个 Partition 可 能 会 非常 小 ， 
如 果 一 个 Partition 非常 小 ， 每 次 都 会 消耗 一 个 线程 去 处 理 的 话 ， 可 能 会 降低 它 的 处 理 效 率 ， 
这 时 候 需 要 考虑 把 许多 小 的 Partition 合并 成 一 个 较 大 的 Partition 去 处 理 ， 这 样 会 提升 效率 。 
另 一 方面 ， 有 可 能 内 存 不 是 那么 多 ， 而 每 个 Partition 的 数据 Block 比较 大 ， 这 时 候 需要 考虑 
把 Partition 变 成 更 小 的 数据 分 片 ， 这 样 会 让 Spark 处 理 更 多 的 批 次 但 是 不 会 出 现 OOM 异常 
(内 存 洲 出 )。 
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i 创建 RDD 的 方式 








中 通过 已 经 存在 的 Scala 集合 创建 RDD ， 


Spark 程序 首先 做 的 第 一 件 事 就 是 创建 一 个 SparkContext 对 象 ， 它 告诉 Spark 如 何 访问 一 
个 集群 。Spark 的 Shell 给 用 户 提 供 了 一 个 简单 强大 的 工具 来 分 析 数 据 交 互 ， 通过 运行 Spark 
目录 下 的 脚本 即 可 启动 它 ， 同 时 Shell 会 创建 一 个 SparkContext 的 变量 sc， 启 动 代码 如 下 。 














1. /bin/spark - shell 





Spark 提供 了 两 种 创建 RDD 的 方式 : 加载 外 部 数据 集 和 在 驱动 程序 中 并 行 集合 。 每 个 
RDD 都 有 Partitioner 属性 ， 它 决定 了 该 RDD 如 何 分 区 ， 当 然 Partition 的 个 数 还 将 决定 每 个 
Stage 的 Task 个 数 。 当 前 Spark 需要 应 用 设置 Stage 的 并 行 Task 个 数 (配置 项 为 : 
spark. default. parallelism) ， 在 未 设置 的 情况 下 ， 子 RDD 会 根据 父 RDD 的 Partition 决定 ， 例 
如 ，map 操作 的 子 RDD 的 Partition 与 父 Partition 完全 一 致 ，Union 操作 的 子 RDD 的 Partition 
个 数 为 父 Partition 个 数值 之 和 。Stage 的 并 行 Task 的 数量 很 大 程度 上 决定 Spark 程序 的 性 能 。 

并 行 集合 ( Parallelized collections) 是 通过 在 一 个 已 有 的 集合 (ScalaSeq) 上 调用 Spark- 
Context 提供 的 parallelize 方法 实现 的 。 集 合 中 的 元 素 被 复制 到 一 个 可 并 行 操作 的 分 布 式 数 据 
集中 。 例 如 ,下面 是 如 何 创建 一 个 数字 1 ~ 5 的 集合 代码 。 








1l. val data = Array(1,2,3,4,5) 


2. val distData = sc. parallelize( data) 


一 旦 创建 完成 ,分布 式 集合 (distData) 可 以 被 并 行 操作 。 例 如 ， 可 能 会 调用 distDa- 
ta. reduce( (a,b) =>a+b) 将 这 个 数组 中 的 元 素 相 加 。 

并 行 集合 有 一 个 很 重要 的 参数 ， 即 切片 数 (slices)， 表 示 一 个 数据 集 的 切片 的 份 数 。 
Spark 会 在 集群 的 每 一 个 分 片上 运行 一 个 任务 ， 集 群 中 的 每 个 CPU 通常 需要 2 一 4 个 分 区 。 
通常 Spark 会 自动 基于 集群 状态 设置 分 区 数目 。 也 可 以 通过 parallelize 的 第 二 个 参数 手动 设 
置 (如 gsc. paralielize( data,10 ) ) 。 注意 : 某 些 地 方 在 代码 中 使 用 数据 分 片 ( 分 区 ) 的 同义词 
来 维持 向 后 兼容 性 。 


必 ED 通 过 HDrs 和 本 地 文件 系统 创建 RDD ) 


从 HDFS 等 外 部 存储 作为 输入 数据 源 ， 数 据 按照 HDFS 中 的 数据 分 布 策略 进行 数据 分 

区 ，HDFS 中 的 一 个 Block 对 应 Spark 的 一 个 分 区 。 生 产 环境 中 最 常用 的 RDD 创建 方式 是 从 

HDFS 来 创建 RDD, SparkContext 中 的 textFile 也 数 从 HDFS 读 取 文件 ， 输 出 变量 fle。file 是 
一 个 RDD， 实 际 是 HadoopRDD 实例 。 案 例 代 码 如 下 。 
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val file = spark. textFile( " hdfs://..." ) 

// 过 滤 包 含 字 符 info 的 信息 的 行 

val infos = file. filter( line => line. contains(“ info” ) ) 
// 统 计 所 有 的 信息 行 的 数量 


val counts = infos. count( ) 


第 1 行 代码 从 Hadoop 文件 系统 (HDFS) 中 定义 了 一 个 RDD ( 即 一 个 文本 行 集合 ) ， 第 
2 行 代码 用 filter 函数 过 滤 带 info 的 行 输出 infos (infos 也 是 一 个 RDD) ， 第 3 行 代码 返回 infos 
的 行 数 。 整 个 转换 的 过 程 如 图 1-3 所 示 。 


RDDO RDDI1 Result RDD 


INEO:info2 
INFO:info3 


INFO:info$ 
INEO:info6 





图 1-3 RDD 创建 及 操作 示意 图 


本 地 文件 系统 创建 RDD， 可 测试 大 量 数 据 的 文件 。 下 面 用 Spark 源 文件 目录 中 的 RE- 
ADME. md 文件 创建 一 个 新 的 RDD ， 代 码 如 下 。 


1 . 
2 


scala > val textFile = sc. textFile(" README. md" ) 
textF'ile :spark. RDD| String] = spark. MappedRDD@ 2ee9b6e3 


RDD 一 旦 创建 完成 ，textFile 就 可 以 做 数据 集 操 作 。 例 如 ， 可 以 用 方法 map 和 Reduce 操 
作 将 所 有 行 的 长 度 相 加 : textFile. map(s =>s. length). reduce( (a,b) =>a+b)。 








其 他 的 RDD 的 转换 ) 








从 父 RDD 转换 可 得 到 新 的 RDD。 通 过 Spark 内 核 给 用 户 提 供 的 Transformation 来 对 RDD 
进行 各 种 算 子 的 转化 ， 形 成 新 的 RDD 实现 算法 。 下 面 通 过 一 段 常用 代码 来 讲解 一 下 ， 代 码 


如 下 。 


ls 
2 








scala > val lines WithSpark = textFile. filter( line => line. contains( " Spark" ) ) 
lines WithSpark :spark. RDDL String | = spark. FilteredRDD@ 7dd4af09 


这 里 涉及 两 个 RDD， 第 一 个 RDD 是 textFile ，textFile 是 一 个 HadoopRDD 经 过 map 后 的 
MapPartitionsRDD ， 第 二 个 RDD 是 经 过 filter 方法 之 后 生成 的 一 个 FilteredRDD， 即 返回 一 个 
新 的 RDD ( 原 RDD 的 子 集 ) 。 

接 下 来 将 要 讲解 上 述 代码 片段 在 Spark 内 部 的 处理 流程 。 首 先 来 看 textFile 方法 ， 进 入 
SparkContext 这 个 类 找到 它 ， 源 代码 如 下 。 








用 


第 1 襄 ， :00)y3 























从 HDFS 读 取 一 个 文本 文件 ,或 从 本 地 文件 系统 (所 有 结 点 上 都 可 用 ) ,或 任何 Hadoop 











* 支持 的 文件 系统 中 ,并 返回 一 个 字符 串 RDD 


*/ 


def textFile( O) 


| 


path :String， 
// 最 小 分 区 数 ,如 果 用 户 没 有 给 定 ,默认 是 两 个 


minPartitions :Int = defaultMinPartitions) :RDDL String | = withScope | 





assertNotStopped ( ) 


hadoopFile( path , classOf[ TextInputFormat | ,classOfL LongWritable ] ， 
classOf| Text | ， 


minPartitions ). map(pair => pair. _2. toString) 


由 SparkContext 类 中 textFile 方法 的 源 代 码 可 知 ，hadoopFile 后 面 加 了 一 个 map 方法 ， 取 
pair 的 第 二 个 参数 ， 最 后 在 shell 里 面 可 看 到 它 是 一 个 MappredRDD 。 默 认 的 defaultMinParti- 
tions 的 大 小 为 2。 源 代码 语句 如 下 。 


1 
2 
3 
4. 
5 
6 





ee 




















* Hadoop RDDs 中 用 户 不 指定 分 区 数 时 的 默认 最 小 分 区 数 
* 注意 所 使 用 的 math. min 的 "defaultMinPartitions" 不 能 大 于 2 
* 这 个 原因 已 在 网 站 https://github. com/mesos/spark/pull/718 中 讨论 过 


*/ 








def defaultMinPartitions :Int = math. min( defaultParallelism ,2 ) 


查看 hadoopFile 方法 的 源 代码 可 知 ，hadoopFile 做 了 3 个 操作 ， 把 Hadoop 的 配置 文件 保 


存 到 广播 变量 里 ， 设 置 了 路 径 ，new 了 一 个 HadoopRDD 返回 。HadoopFile 方法 的 源 代码 如 下 。 





ee 





得 到 一 个 Hadoop 文件 中 任意 InputFormat 的 RDD */ 

def hadoopFile[ K,V]( 

path :String， 

inputFormatClass:Class| _ < :InputFormat[ K,V|] ]， 

keyClass: Class| 下] ， 

valueClass: Class| V | ， 

// 最 小 分 区 数 ,如 果 用 户 没 有 给 定 ,默认 是 两 个 

minPartitions :Int = defaultMinPartitions) : RDD[ ( K,V) | =withScope | 

assertNotStopped( ) 

// 一 个 Hadoop 的 配置 可 以 约 10 kb, 这 是 相当 大 的 ,为 了 减少 通信 开销 所 以 采用 广播 
3 

val confBroadcast = broadcast( new SerializableConfiguration( hadoopConfiguration ) ) 

val setInputPathsFunc = (jobConf:JobConf) => FileInputFormat. setInputPaths( jobConf, 


path) 
new HadoopRDD( 
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15. Tk. 

16. confBroadcast, 

17. Some( setInputPathsFunc ) ， 

18. inputFormatClass, 

19. keyClass ， 

20. valueClass, 

2 minPartitions ). setName( path ) 
2 } 








接 下 来 分 析 HadoopRDD， 通 过 以 下 源 代码 可 知 ，HadoopRDD 是 一 个 对 象 。 


1. private[ spark | object HadoopRDD extends Logging 





HadoopRDD 也 是 RDD， 由 于 RDD 具有 五 大 特性 ， 所 以 重点 关注 它 的 getPartitions 方法 、 
compute 方法 和 getPreferredLocations 方法 。 先 看 getPartitions 方法 ， 源 代码 如 下 。 


1. override def getPartitions: Array[ Partition ] = | 

2 val jobConf = getJobConf( ) 

3 //SparkContext 初始 化 之 前 被 调用 ,在 此 处 添加 credentials 
4 SparkHadoopUtil. get. addCredentials( jobConf) 

5. // 输 入 格式 

6 val inputFormat = getInputFormat( jobConf) 

7 // 输 入 分 片 

8 val inputSplits = inputFormat. getSplits( jobConf ,minPartitions ) 
9 // 得 到 数组 

10. val array = new Array[ Partition | (inputSplits. size ) 

11. for(i <—0 until inputSplits. size) | 

2 array(1) =new HadoopPartition( id,i, inputSplits( 1) ) 

13. | 

14. array 

15. | 





它 调用 的 是 inputFormat 自 带 的 getSplits 方法 来 计算 分 片 ， 然 后 把 分 片 HadoopPartition 包 
装 到 Array 数组 里 面 返 回 。 
接 下 来 分 析 HadoopRDD 的 compute 方法 ， 源 代码 如 下 。 


override def compute( theSplit:Partition ,context :TaskContext) : Interruptiblelterator[ (K,V)]=| 
val iter = new Nextlterator| (K,V) ] | 

// 转 换 成 HadoopPartition 

val split = theSplit. asInstanceOf| HadoopPartition | 

logInfo( " Input split:" + split. inputSplit) 

val jobConf = getJobConf( ) 

val inputMetrics = context taskMetrics. getInputMetricsForReadMethod ( DataRead Method. Hadoop) 


BA A re NE 
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// 为 文件 名 设置 线程 局 部 变量 
; split inputSplit. value match | 
10. case fs:FileSplit => SqlNewHadoopRDDState. setInputFileName( fs. getPath. toString ) 


11. case _ => SqlNewHadoopRDDState. unsetInputFileName( ) O) 
12. | 





13. [tr 找到 一 个 函数 ,该 函数 将 返回 这 个 线程 读 取 的 文件 系统 字 节 。 做 这 之 前 先 创建 
RecordReader, 因为 RecordReader 的 构造 函数 可 以 读 取 一 些 字 节 */ 











14. val bytesReadCallback = inputMetrics. bytesReadCallback. orElse | 

15. split. inputSplit. value match | 

16. case _:FileSplit | _:CombineFileSplit => 

17. SparkHadoopUtil. get. getF SBytesReadOnThreadCallback( ) 

18. case _ => None 

19. | 

20. | 

2 inputMetrics. setBytesReadCallback( bytesReadCallback ) 

2 // 通 过 Inputform 的 getRecordReader 来 创建 InputSpit 的 Reader 

23: var reader: RecordReader[ K,V|] =null 

24. val inputFormat = getInputFormat( jobConf) 

25， HadoopRDD. addLocalConfiguration ( new SimpleDateFormat ( " yyyyMMddHHmm" ) . format 
(createTime ) ， 

26. context. stageld ,theSplit index ,context. attemptNumber ,jobConf ) 

2 reader = inputFormat. getRecordReader( split inputSplit. value ,jobConf, Reporter NULL) 

28. // 注册 一 个 任务 完成 回调 ,以 关闭 输入 流 

29. context. addTaskCompletionListener | context => closelfNeeded( ) } 

30. ”// 调 用 Reader 的 next 方法 

31. val key:K = reader. createKey( ) 

32. val value:V = reader. createValue( ) 

3 override def getNext( ) :(K,V) =| 

34. try | 

S35, finished = !reader. next( key, value) 

36. | catch | 

3 大 case eof:EOFException => 

38. finished = true 

39. | 

40. if( lfinished) | 

41. inputMetrics. incRecordsRead( 1) 

42. | 

43. ( key , value) 

45. override def close( ) | 

46. if(reader !=null) | 

47. SqlNewHadoopRDDState. unsetInputFileName( ) 
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48. // 关 闭 reader 并 释放 它 

49. try | 

50. reader. close( ) 

Sl | catch | 

SS case e:Exception => 

S93 if ( !ShutdownHook Manager. inShutdown( ) ) | 

54. logWarning( " Exception in RecordReader. close( )" ,e) 

5 | 

50. | finally | 

D7 reader = null 

58. } 

59. if ( bytesReadCallback. isDefined ) | 

60. inputMetrics. updateBytesRead ( ) 

61. | else if (split. inputSplit value. isInstanceOf[ FileSplit] | 

62. split. inputSplit. value. isInstanceOf| CombineFileSplit | ) | 
03. try | 

64. // 如 果 不 能 从 FS 中 读 取 数据 字 节 ,分 区 的 大 小 可 能 是 不 准确 的 
05. inputMetrics. incBytesRead ( split. inputSplit. value. getLength ) 
66. | catch | 

07. case e:java. 10. IJOException => 

68. logWarning( " Unable to get input size to set InputMetrics for task" ,e) 
69. | 

70. 

Fle } 

而 | 

7 | 

74. new Interruptiblelterator[ (K,V) ] (context ,iter) 

7 } 








HadoopRDD 的 输入 值 是 一 个 Partition ， 返 回 值 是 一 个 Iterator[ (K,V) ] 类 型 的 数据 ， 这 里 
只 关注 两 点 即 可 : 把 Partition 转换 成 HadoopPartition ， 然 后 通过 InputSplit 创建 一 个 Recor- 
dReader; 重 写 Tterator 的 getNext 方法 ， 通 过 创建 的 reader 调用 next 方法 读 取 下 一 个 值 。 从 这 
里 可 以 看 出 ， compute 方法 是 通过 分 片 来 获得 Iterator 接口 的 ， 遍 历 分 片 的 数据 。 

接 下 来 分 析 getPreferredLocations 方法 ， 该 方法 通过 调用 InputSplit 接口 的 getLocations 方 
法 获得 RDD 所 在 的 位 置 。 源 代码 如 下 。 

















override def getPreferredLocations( split: Partition) :Seq[ String] = | 
val hsplit = split. asInstanceOf[ HadoopPartition |. inputSplit. value 
val locs: Option|[ Seq[ String ] ] = HadoopRDD. SPLIT_INFO_REFLECTIONS match | 
case Some(c) => 
try | 
vallsplit = c. inputSplitWithLocationInfo. cast( hsplit) 


A ee 
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允 // 获 得 RDD 的 位 置信 息 
val infos = c. getLocationInfo. invoke( lsplit). asInstanceOf[ Array[ AnyRef | | 
9. Some( HadoopRDD. convertSplitLocationInfo( infos ) ) 
10. | catch | O) 
11. case e: 上 Exception => 
12. //debug 异常 日 志 信息 
3 logDebug( " Failed to use InputSplitWithLocations. " ,e) 
14. None 
15. | 
16. case None => None 
记 | 
18. locs. getOrElse( hsplit getLocations. filter( _ != "localhost" ) ) 
19 


最 后 分 析 MapPartitionsRDD， 首 先 了 解 一 下 RDD 类 里 面 的 map 方法 ，map 方法 的 源 代码 
如 下 。 








1. /x** RDD 中 的 每 个 元 素 都 经 过 函数 {处 理 后 返回 一 个 新 的 RDD */ 
2. def map[ U:ClassTag |](f:T=> U):RDD[U] =withScope | 

3: val cleanF = sc. clean(f) 
4. 

3: 





new MapPartitionsRDDI U,T | (this, (context, pid , iter) => iter map( cleanF ) ) 
| 


从 map 方法 的 源 代 码 可 知 ，map 方法 内 部 直接 new 了 一 个 MapPartitionsRDD， 还 把 匿名 
函数 { 处 理 来 再 传 进去 ， 接 下 来 展开 MapPartitionsRDD ，MapPartitionsRDD 的 源 代码 如 下 : 








1. [RDD 对 父 RDD 的 每 个 分 区 提供 的 功能 

2. private[ spark | class MapPartitionsRDD[ U.:ClassTag,T.ClassTag | ( 
3 prev: RDD[ T],， 

4 ZLA(TaskContext ,分 区 索引 ,迭代 器 ) 

3 f: (TaskContext, Int, Iterator[ T | ) => TIterator[ U ] ， 
6 

% 

8 

9 





preservesPartitioning : Boolean = false ) 
extends RDD| U | ( prev) | 
override val partitioner = if( preservesPartitioning ) firstParent[ T]. partitioner else 
None 
10. override def getPartitions : Array[ Partition | = firstParent[ T]. partitions 
11. override def compute( split: Partition,context: TaskContext) :Iterator[ U] = 
2 f( context, split. index , firstParent[ T ]. iterator( split, context ) ) 
Bo 


由 MapPartitionsRDD 的 源 代码 可 知 ，MapPartitionsRDD 把 父 类 RDD 的 partitioner 、getPar- 
titions 和 compute 给 重 写 了 ， 而 且 每 个 分 区 的 compute 中 都 用 到 了 firstParent[T] 方 法 ，first- 
Parent[ T] 方 法 的 源 代码 如 下 。 
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/#* 返回 第 一 个 父 RDD */ 





1 
多 protected[ spark | deffirstParent| U :ClassTag| :RDD[U] =| 
3 dependencies. head. rdd. asInstanceOf[ RDD[ U |] |] 

4 | 


继续 追踪 方法 dependencies ，dependencies 的 源 代 码 如 下 。 


1. Asx# 得 到 这 个 RDD 的 依赖 列表 ,要 考虑 这 个 RDD 是 否 需要 检查 点 */ 

2 final def dependencies:Seq[ Dependency[_]] = | 

3 checkpointRDD. map(r => List(new OneToOneDependency(r) ) ). getOrElse | 
4 if (dependencies_ == null) | 

SS dependencies_ = getDependencies 

6 | 

7 dependencies_ 

8 | 

9 | 


由 此 可 以 得 出 两 个 结论 : (DgetPartitions 直接 沿用 了 父 RDD 的 分 片 信 息 。@@compute 函 
数 是 通过 RDD 遍历 每 一 个 数 时 接受 一 个 匿名 函数 f 进行 处 理 的 。 现在 应 该 可 以 看 出 compute 
函数 有 两 个 显著 的 作用 ， 一 个 是 在 没有 依赖 的 条 件 下 ， 根 据 分 片 的 信息 生成 遍历 数据 的 Tter- 
able 接口 ; 另 一 个 是 在 有 前 置 依赖 的 条 件 下 ， 在 父 RDD 的 Iterable 接口 上 遍历 每 个 元 素 时 再 
接受 一 个 方法 处 理 。 


4 其 他 的 RDD 的 创建 


基于 DB 创建 RDD、 基 于 S3 (3S3 是 一 个 公开 的 、 云 存储 服务 ，Web 应 用 程序 开发 人 员 
可 以 使 用 它 存储 数字 资产 ， 包括 图 片 、 视 频 、 音 乐 和 文档 ) 创建 RDD， 或 基于 数据 流 创建 
RDD 等 是 比较 常见 的 创建 初始 化 RDD 的 方式 。 接 下 来 的 一 个 创建 RDD 的 案例 ， 是 从 
MySQL 关系 型 数据 库 中 读 取 数据 ， 最 终 得 到 RDD 类 型 的 数据 。 在 Spark 中 提供 了 一 个 Jdb- 
cRDD 的 类 ， 这 个 JdbcRDD 执行 一 个 SQL 查询 和 JDBC 链接 读 取 结果 ， 也 就 是 说 该 RDD 就 
是 读 取 JDBC 中 的 数据 并 转换 成 RDD。 

首先 来 看 看 该 类 的 构造 函数 ， 源 代码 如 下 。 

















/六 六 

x* @ param getConnection /返回 一 个 打开 链接 的 函数 
这 个 RDD 同样 关注 链接 的 关闭 

* @ param sql sql 的 查询 语句 

查询 必须 包含 两 个 用 于 分 区 结果 参数 占 位 符 

* @ param lowerBound 最 小 值 的 第 一 个 占 位 符 

* @ param upperBound 最 大 值 的 第 二 个 占 位 符 

*# ”上 线 和 下 线 的 边界 

x* @ param numPartitions 分 区 数 

给 定 一 个 下 边界 为 1, 上 边界 为 20, 分 区 数 为 2 
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11. * 该 查询 被 执行 两 次 ,一 次 (1,10) 和 一 次 (11 ,20) 

12. * @param mapRow 一 个 结果 集 的 函数 ,所 需 结 果 类 型 的 一 行 

13. #* 是 转换 函数 ,将 返回 的 ResultSet 转 成 RDD 需 用 的 单行 数据 ,此 处 可 以 选择 Array 或 
14. * ”其 他 ,也 可 以 是 自 定义 的 case class。 默 认 将 ResultSet 转换 成 一 个 Object 数组 

下 SS 

16. class JdbeRDDIT:ClassTag |] ( 

17. sc: SparkContext, 

















18. getConnection:() => Connection, 

19. sql: String, 

20. lowerBound: Long, 

21. upperBound: Long, 

22. numPartitions: Int, 

23. mapRow: (ResultSet) => T=JdbcRDD. resultSetToObjectArray _) 
24. extends RDD[ T| (sc,Nil)with Logging 





这 个 类 带 了 很 多 参数 ， 上 述 源 代码 处 已 给 出 解释 。 接 下 来 是 一 段 从 MySQL 中 读 取 数据 
创建 RDD 的 代码 示例 ， 代 码 如 下 。 





1. def main( args:Array[ String] ) | 

2. val sc =new SparkContext("local" ,"mysql" ) 

3. val rddResult = new JdbcRDD( 

4. sc， 

53 

6. Class. forName( "com. mysql. jdbe. Driver" ). newInstance( ) 

7. DriverManager. getConnection( " jdbce:mysql://localhost:3306/db" , "root" ,"123456" ) 
8. |}， 

9. "SELECT content FROM test WHERE ID >=? AND ID < =?"， 
10. 1 ,100 ,3 ， 

11. r=> r. getString(1) ). cache() 

| } 


上 述 代 码 用 于 读 取 MySQL 中 test 表 中 的 数据 ， 并 统计 ID 大 于 等 于 1 且 小 于 等 于 100 的 
记录 集合 ， 得 到 结果 集 变 量 rddResult， 从 代码 中 可 以 看 出 ，JdbcRDD 的 sql 参数 带 有 两 个 ? 
的 占 位 符 ， 而 这 两 个 占 位 符 是 参数 lowerBound 和 参数 upperBound 定义 where 语句 的 上 下 边 
界 ， 从 JdbcRDD 类 的 构造 函数 可 知 ， 参 数 lowerBound 和 参数 upperBound 都 只 能 是 Long 类 型 
的 ， 并 不 支持 其 他 类 型 的 比较 ， 这 个 使 得 JdbhcRDD 使 用 的 函数 将 比较 有 限 。 结 合 上 述 的 两 
段 代 码 可 知 ，Spark 的 JdbcRDD 最 终 链接 MySQL 数据 库 并 读 取 数 据 ， 并 最 终生 成 RDD。 






































- 四 RDD 算 子 


Spark 在 运行 中 通过 算 子 对 RDD 进行 计算 ， 算 子 是 RDD 中 定义 的 函数 ， 可 以 对 RDD 中 





















































存储 (e.g.HDFS) Scala 和 集合 数据 类 型 Scala 标 量 类 型 








Spark RDD 空 间 


1-4 RDD 中 的 算 子 运算 流程 图 





1. 输入 

在 Spark 程序 运行 中 ， 数 据 从 外 部 数据 空间 (如 分 布 式 存储 ，textFile 读 取 HDFS 等 ， 
parallelize 方法 输入 Scala 集合 或 数据 ) 输入 Spark ， 数 据 进 入 Spark 运行 时 数据 空间 ， 转 换 
为 Spark 中 的 数据 块 ， 通 过 BlockManager 进行 管理 。 

2. 运行 

在 Spark 数据 输入 形成 RDD 后 ， 可 以 通过 变换 算 子 (Transformation 算 子 )， 如 filter 等 ， 
对 数据 进行 操作 ， 并 将 RDD 转化 为 新 的 RDD， 通 过 Action 算 子 ， 触 发 Spark 提交 作业 。 如 
果 数 据 需 要 复 用 ， 可 以 通过 Cache 算 子 将 数据 缓存 到 内 存 中 。 

3. 输出 

程序 运行 结束 后 数据 会 输出 Spark 运行 时 的 空间 ， 存 储 到 分 布 式 存储 中 《如 saveAsTexr- 
File 输出 到 HDFS) ， 或 Scala 类 型 的 数据 或 集合 中 (collect 输出 到 Scala 集合 ，count 返回 
Scala int 型 数据 ) 。 

Spark 中 生成 的 不 同 RDD 中 ， 有 的 和 用 户 逻 辑 显示 的 对 应 ， 如 map 操作 生成 MapParti- 
tionsRDD ， 而 有 的 RDD 则 是 Spark 框架 帮助 用 户 隐 式 生 成 的 ， 如 reduceByKey 操作 时 的 Shuf- 
fleRDD 等 。Spark 的 核心 数据 模型 是 RDD， 但 RDD 是 一 个 抽象 类 ， 具 体 由 各 子 类 实现 ， 如 
MappedRDD 、ShuffledRDD 等 子 类 。 在 Spark 的 reduceByKey 操作 时 会 触发 Shuffle 的 过 程 ， 
在 Shuffle 之 前 ， 会 有 本 地 的 聚合 过 程 产生 MapPartitionsRDD ， 接 着 具体 Shuffle 会 产生 Shuf- 
fledRDD， 之 后 做 全 局 的 聚合 生成 结果 MapPartitionsRDD。Spark 将 常用 的 大 数据 操作 都 转化 











E 浊 证 谓 以 RDD 功 能 解析 


成 RDD 的 子 类 ， 如 图 1-5 所 示 。 


Transformation 


flatmap 


saveAsSequenceFile 
Stage3 





图 1-5 Spark 操作 数据 模型 图 


SparkRDD 中 的 算 子 大 致 可 分 为 下 列 三 大 类 。 

1) Value 数据 类 型 的 Transformation 算 子 ， 这 种 变换 并 不 触发 提交 作业 ， 针 对 处 理 的 数 
据 项 是 Value 型 的 数据 。 

2) Key - Value 数据 类 型 的 Transfromation 算 子 ， 这 种 变换 并 不 触发 提交 作业 ， 针 对 处 理 
的 数据 项 是 Key - Value 型 的 数据 对 。 

3) Action 算 子 ， 这 类 算 子 会 触发 SparkContext 提交 Job 作业 ， 一 个 Job 包含 多 个 Stage 
(至 少 一 个 Stage) ，Stage 内 部 由 一 组 完全 相同 的 Task 构成 ， 这些 Task 只 是 处 理 的 数据 不 同 ; 
一 个 Stage 的 开始 就 是 从 外 部 存储 或 者 Shuffle 结果 中 读 取 数据 ， 一 个 Stage 的 结束 是 由 于 要 
发 送 Shuffle 或 者 生成 最 终 的 计算 结果 。 

对 于 Spark 中 的 Join 操作 ， 如 果 每 个 Partition 仅仅 和 特定 的 Partition 进行 Join， 那 么 就 
是 窗 人 依赖， 对 于 需要 parent RDD 所 有 的 partition 进行 Join 的 操作 ， 即 需要 Shuffle ， 此 时 就 是 
宽 依 赖 。RDD 的 saveAsTextFile 方法 会 首先 生成 一 个 MapPartitionsRDD ， 该 RDD 通过 调用 
PairRDDFunctions 的 saveAsHadoopDataset 方法 向 HDFS 等 输出 RDD 数据 的 内 容 ， 并 在 最 后 调 
用 SparkContext 的 runJob 来 真正 向 Spark 集群 提交 计算 任务 。 
默认 情况 下 ， 每 一 个 Transformaton 过 的 RDD 会 在 每 次 Action 时 重新 计算 一 次 ， 然 而 ， 
可 以 使 用 Persist (或 Cache) 持久 化 一 个 RDD 到 内 存 中 ， 可 进行 复 用 。 根 据 Action 算 子 的 
输出 空间 将 Action 算 子 进行 分 类 : 无 输出 、HDFS 、Scala 集合 和 数据 类 型 ，RDD 模型 适合 粗 
粒度 的 全 局 数据 并 行 计算 ， 不 支持 细 粒 度 的 异步 更 新 操作 和 增 量 迭 代 计 算 。 

基于 RDD 的 整个 计算 过 程 都 是 发 生 在 Worker 中 的 Executor 中 的 。RDD 支持 3 种 类 型 的 
操作 : Transformation 、Action， 以 及 以 Persist 和 CheckPoint 为 代表 的 控制 类 型 的 操作 。RDD 
一 般 会 从 外 部 数据 源 读 取 数据 ， 经 过 多 次 RDD 的 Transformation (中 间 为 了 容错 和 提高 效 
率 ， 有 可 能 使 用 Persist 和 CheckPoint) ， 最 终 通 过 Action 类 型 的 操作 一 般 会 把 结果 写 回 外 部 
存储 系统 。Spark Checkpoint 通过 将 RDD 写 入 磁盘 做 检查 点 ， 是 Spark Lineage 容错 机 制 的 辅 
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助 ，Lineage 过 长 会 造成 容错 成 本 过 高 ， 此 时 在 中 间 阶 段 做 检查 点 容错 ， 如 果 之 后 有 结 点 出 
现 问题 而 丢失 分 区 ， 从 检查 点 的 RDD 开始 重 做 Lineage 就 会 减少 开销 。Checkpoint 主要 适用 








于 以 下 两 种 情况 : DDAG 中 的 Lineage 过 长 ， 若 重 算 开销 会 太 大 ， 如 在 PageRank 、ALS 等 ; 
@ 尤 其 适合 于 在 宽 依赖 上 做 Checkpoint， 这 个 时 候 就 可 以 避免 为 Lineage 重新 计算 而 带 来 的 
匈 余 计算 。 





Es RDD 的 Transformation 算 子 
县 加 Transformation 的 定义 | 





Transformation 是 一 种 算法 的 描述 。 标 记 着 需要 进行 操作 的 数据 ， 但 不 真正 执行 。Trans- 
formation 具有 Lazy 特性 ， 操 作 是 延迟 计算 的 。 也 就 是 说 从 一 个 RDD 转换 成 男 一 个 RDD 的 转 
换 操 作 不 是 马上 执行 ， 需要 等 到 有 Actions 操作 或 Checkpoint 操作 时 ， 才 真正 触发 操作 。 通 
过 Lazy 特性 底层 的 Spark 程序 才能 对 应 用 程序 进行 优化 。 为 什么 通过 Lazy 特性 Spark 就 能 对 
应 用 程序 进行 优化 呢 ? 因为 一 直 是 延迟 执行 的 Spark 框架 能 够 观察 到 很 多 运算 步骤 ， 观 察 到 
的 越 多 ， 对 其 进行 优化 的 机 会 就 越 多 。 


Transformation 在 RDD 中 的 角色 定位 及 功能 


Transformation 作为 算 子 〈 算 子 是 RDD 中 定义 的 函数 ， 可 以 对 RDD 中 的 数据 进行 转换 和 
操作 ) 的 一 个 抽象 概念 ， 从 已 经 存在 的 数据 集中 创建 一 个 新 的 数据 集 ，Transformation 都 具 
有 Lazy 特性 ， 不 立即 计算 RDD 的 结果 ， 仅 仅 记录 转换 操作 应 用 到 哪些 RDD 上 ，Transforma- 
tion 仅仅 在 执行 Action 时 才 进 行 计 算 (起 作用 ) ， 在 Action 之 前 不 发 生动 作 。 

Transformation (变换 ) 算 子 中 可 以 将 数据 类 型 维度 细 分 为 Value 数据 类 型 和 Key - Value 
对 数据 类 型 的 Transformation 算 子 。Value 型 数据 的 算 子 封装 在 RDD 类 中 可 以 直接 使 用 ， 
Key -Value 对 数据 类 型 的 算 子 封装 在 PairRDDFunctions 类 中 。 


Transformation 操作 的 Lazy 特性 


Action 要 数据 的 时 候 Transformation 才 会 开始 工作 ，Spark 里 任何 一 个 正常 的 作业 都 是 没 
有 进行 计算 的 ， 最 后 一 步 要 生成 结果 时 ， 从 后 往 前 回溯 父 RDD 有 没有 计算 ， 以 及 其 父 RDD 
的 父 RDD 有 没有 计算 ， 从 后 往 前 推 ， 这 就 是 Transformation 的 Lazy 特性 ， 这 样 一 个 特性 有 一 
个 非常 大 的 好 处 ， 就 是 不 需要 结果 时 就 不 让 这 个 作业 进行 计算 ， 而 在 需要 结果 时 它 才 发 生 具 
体 的 计算 ， 这 样 就 可 以 避免 产生 很 多 不 必要 的 中 间 临 时 数据 ， 这 比较 符合 分 布 式 并 行 计 算 的 
需求 ; 另外 一 个 层面 是 调度 层面 ， 最 后 一 步 要 计算 时 ， 可 以 看 到 前 面 的 所 有 步 又， 看 见 的 步 
又 越 多 ， 进 行 优化 的 机 会 就 越 多 ， 所 以 Spark 是 基于 Lazy 特性 进行 操作 、 基 于 Linage (血统 
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继承 关系 ) 来 构建 其 整个 调度 系统 的 ， 最终 形成 了 有 向 无 环 图 (Directed Acyclic Graph ， 
DAG)。 需 要 特别 注意 的 是 ， 计 算是 在 Actions 或 Checkpoint 阶段 ， 计 算是 从 后 往 前 回溯 ， 优 
化 由 此 开始 〈 回 湖 和 优化 都 发 生 在 Driver 上 ) 。 


通过 实践 说 明 Transformation 的 Lazy 特性 








下 面 以 计算 出 Spark 源 文件 目录 中 的 README. md 文件 中 找到 最 大 的 行 数 为 例 来 说 明 
transformation 算 子 Lazy 的 特性 ， 代 码 如 下 (其 中 的 map 算 子 即 为 Transformation 算 子 ) 。 


scala > importjava. lang. Math 

importjava. lang. Math 

scala > textFile. map( line => line. split("" ). size). reduce( (a,b) => Math. max(a,b)) 
res9 :Int =15 


or ed 


map 创建 一 个 新 的 RDD ，reduce 在 RDD 上 调用 Math. max( ) 方 法 找到 最 大 的 行 数 ，map 
由 于 Lazy 特性 不 立即 计算 ，reduce 用 于 执行 是 一 个 action。 此 时 Spark 把 计算 分 成 多 个 
Task， 并 且 运 行 在 多 个 机 器 上 ， 每 台 机 融 都 运行 自己 的 map 和 reduce， 最 后 只 把 结果 返回 给 
Driver。 要 想 证 明 上 述 代 码 的 map 算 子 具有 的 Lazy 特性 ， 只 需 在 此 基础 上 指定 一 个 错误 (不 
存在 的 ) 的 文件 路 径 ， 然 后 再 执行 即 可 ， 执 行 后 并 没有 报错 ， 所 以 上 述 代码 的 map 算 子 是 
Lazy 级 别 的 ， 因 为 它 并 没有 发 生计 算 。 





区 RDD 的 Action 算 子 
61 Action 的 定义 ) 





Action 是 一 种 算法 的 描述 ， 它 通过 SparkContext 触发 一 个 Job 向 用 户 程 序 返 回 一 个 值 或 
一 个 结果 。 当 要 求 返回 RDD (数据 集 ) 给 Driver 时 ， Transformations 会 得 到 一 个 新 的 RDD ， 
方式 很 多 ， 比 如 从 数据 源 生成 一 个 新 的 RDD ， 从 RDD 生成 一 个 新 的 RDD。 


Ee Action 在 RDD 中 的 角色 定位 及 功能 ) 


Action 算 子 会 触发 SparkContext 的 runJob 方法 提交 作业 (Job)， 触 发 RDD DAG 的 执行 
并 将 数据 输出 到 Spark 系统 。Action 在 RDD (数据 集 ) 上 进行 计算 之 后 返回 一 个 值 到 Driv- 
er， 这 样 设计 能 让 Spark 运行 得 更 高 效 。 

Spark 中 的 RDD 转换 (Transformation) 和 动作 ( Action) ， 每 个 操作 都 给 出 标识 ， 其 中 
方 括号 表示 类 型 参数 。 前 面 说 过 Transformation 是 延迟 操作 ， 用 于 定义 新 的 RDD; 而 Action 
启动 计算 操作 ， 并 向 应 用 程序 返回 值 或 向 外 部 存储 写 数据 。 

在 Spark 中 ，RDD 被 表示 为 对 象 ， 通 过 这 些 对 象 上 的 方法 或 吃 数 调用 Transformation。 定 
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义 RDD 之 后 ， 可 以 在 Action 中 使 用 RDD。Action 是 向 应 用 程序 返回 值 或 向 存储 系统 导出 数 
据 的 那些 操作 ， 如 count (返回 RDD 中 的 元 素 个 数 )、collect (返回 元 素 本 身 ) 和 save (将 
RDD 输出 到 存储 系统 )。 在 Spark 中 ， 只 有 在 Action 第 一 次 使 用 RDD 时 ， 才 会 计算 RDD 
( 即 延迟 计算 )。 这 样 在 构建 RDD 时 ， 运 行 时 通过 Pipline 方法 传输 多 个 Transformation 算 子 。 





另外 RDD 还 允许 根据 关键 字 (key) 指定 分 区 顺序 ， 这 是 一 个 可 选 的 功能 。 目 前 支持 Hash 
分 区 和 Range 分 区 ， 例 如 ， 应 用 程序 请 求 将 两 个 RDD 按照 同样 的 Hash 方式 进行 分 区 (将 同 
一 机 吉 上 具有 相同 关键 字 的 记录 放 在 一 个 分 区 ) ， 以 加 速 它们 之 间 的 join 操作 ， 多 次 迭代 之 
间 采 用 一 致 的 分 区 置换 策略 进行 优化 ， 人 允许 指定 这 样 的 优化 。 

RDD 提供 了 很 多 Transformations 操作 算 子 ， 每 个 转换 操作 算 子 都 会 生成 新 的 RDD， 新 
的 RDD 依赖 于 原 有 的 RDD， 这 种 RDD 之 间 的 依赖 关系 最 终 形成 DAG。DAG 经 过 Shuffle 处 
理 后 形成 Stage。 表 1-1 列 出 了 一 些 常 用 的 算 子 。 

表 1-1 常用 算 子 表 
算 子 分 类 集体 算 子 名 称 


map( func) 











filter( func ) 





flatMap(func ) 





mapPartitions( func ) 





sample( withReplacement ,fraction ,seed ) 





union( withReplacement ,fraction ,seed ) 





Transformation intersection ( otherDataset ) 





distinct( [ numTask ] ) 





groupByKey( [ numTasks | ) 





reduceByKey (func, [ numTasks | ) 





aggregateByKey( zeroValue ) ( seqOp ,combOp, [ numTasks | ) 





sortByKey( [ ascending | , [ numTasks | ) 





join( otherDataset, [ numTasks ] ) 





reduce( func) 





collect( ) 





Action count( ) 





first( ) 





take( n) 





有 些 hash 值 针 对 Key - Value 刍 值 对 可 用 ,例如 groupByKey， 另外， 水 数 名 与 Scala 及 
其 他 函数 式 语言 中 的 API 匹配 ， 例 如 ，map 是 一 对 一 的 映射 ， 而 flatMap 是 将 每 个 输入 映射 
为 一 个 或 多 个 输出 。 用 户 可 以 通过 Partitioner 类 获取 RDD 的 分 区 顺序 ， 然 后 将 另 一 个 RDD 
按照 同样 的 方式 分 区 。 有 些 操 作 会 自动 产生 一 个 hash 或 范围 分 区 的 RDD， 如 groupByKey、 
reduceByKey 和 sort 等 。 





RDD 功 能 解析 





小 结 


本 章 主要 介绍 了 以 下 内 容 : RDD 产生 的 技术 背景 及 功能 ，RDD 基本 概念 ， 创 建 RDD 的 
方式 ，RDD 的 Transformation 算 子 ， RDD 的 Action 算 子 及 RDD 的 Transformation 及 Action 常 
用 算 子 列表 。RDD 是 Spark 大 数据 计算 的 基石 ， 通 过 本 章 对 Spark RDD 内 容 的 学 习 ， 可 以 进 
一 步 学 习 Spark SQL、Spark Streaming 、Spark ML 及 图 计算 的 学 习 打 下 坚实 的 基础 。 











内 核 机 制 解析 及 性 能 调 优 


第 2 但 ”RDD 的 运行 机 制 


本 节 内 容 主 要 讲解 关于 RDD 运行 机 制 。 内 容 包 括 RDD 依赖 关系 的 意义 与 形成 原因 ， 基 
于 RDD 依赖 关系 形成 有 向 无 环 图 的 过 程 ，RDD 计算 究竟 是 通过 何 种 流程 进行 的 ， 以 及 在 计 
算 中 如 何 通过 RDD 缓存 (Cache) 、 检 查 点 〈Checkpoint) 等 容错 技术 进行 容错 。 


RDD 依赖 关系 


RDD 的 依赖 关系 是 在 整个 Spark 计算 过 程 中 尤为 重要 的 一 部 分 ， 涉 及 基于 RDD 计算 的 
方方面面 ， 还 对 于 DAG 的 形成 起 着 决定 性 的 作用 。 本 节 主 要 从 RDD 依赖 关系 的 分 类 角度 分 
别 讲解 RDD 的 罕 依 赖 和 宽 依 赖 。 








窄 依 赖 (Narrow Dependency) 








RDD 的 窄 依赖 是 RDD 中 最 常见 的 依赖 关系 ， 用 于 表示 每 一 个 父 RDD 中 的 Partition 最 多 
被 子 RDD 的 工 个 Partition 所 使 用 ， 如 图 2-1 所 示 , 父 RDD 有 2 一 3 个 Partition， 每 一 个 分 
区 都 只 对 应 子 RDD 的 1 个 Partition 。 


窄 依赖 





map, filter 





与 协同 分 区 的 输入 
值 进 行 join 操 作 








union 


图 2-1 窄 依 赖 关系 图 














在 Spark 的 源 代 码 中 ， 把 窄 依赖 分 为 两 类 : 一 类 是 一 对 一 的 依赖 关系 ,在 Spark 中 用 
OneToOneDependency 来 表示 ， 它 表示 父 RDD 与 子 RDD 的 依赖 关系 是 一 对 一 的 依赖 关系 ， 
如 图 2-1 中 所 示 的 map、filter 和 join with inputs co - partitioned; 第 二 类 是 范围 依赖 关系 ， 在 
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Spark 中 用 RangeDependency 表示 ， 它 表示 父 RDD 与 子 RDD 的 依赖 关系 是 一 对 一 的 范围 内 
的 依赖 关系 。 如 图 2-1 中 所 示 的 union。 

接 下 来 通过 Spark 关于 这 两 种 依赖 关系 的 源 代码 来 分 析 这 两 种 依赖 关系 具体 在 Spark 中 
的 实现 方式 。 

Spark 关于 依赖 关系 的 源 代码 位 于 Dependency. scala 文件 中 ， 其 中 关于 OneToOneDepen- 
dency 的 内 容 如 下 所 示 。 





1. class OneToOneDependency[ T| (rdd:RDD|T|])extends NarrowDependency[ T | (rdd)| 
2. override def getParents( partitionld :Int) :List[ Int] = List(partitionId ) 


可 以 看 到 ，Spark 的 重 写 方法 引入 了 参数 partitionId ， 而 在 具体 的 方法 中 也 使 用 了 这 
数 ， 这 表明 子 RDD 在 通过 getParents 方法 时 ， 查 询 的 是 相同 partitionId 的 内 容 ， 
RDD 仅仅 依赖 父 RDD 中 相同 partitionID 的 Partition。 

而 Spark 中 关于 罕 依 赖 还 有 第 二 种 依赖 关系 ， 即 RangeDependency，Spark 源 代码 中 关于 
它 的 内 容 如 下 所 示 。 

















override def getParents( partitionId :Int) :List| Int] = | 

if (partitionId >= outStart && partitionld < outStart + length ) | 
List( partitionld - outStart + inStart ) } 

else | Nil | 

| 


Cr Ce 





从 代码 中 可 以 看 到 ，RangeDependency 和 OneToOneDependency 最 大 的 区 别 是 其 实现 方法 
中 出 现 了 outStart 、length 和 instart 参数 ， 子 RDD 在 通过 getParents 方法 查询 对 应 的 Partition 
时 ， 会 根据 这 个 partitionId 减 去 插入 时 的 开始 DD， 再 加 上 它 在 父 RDD 中 的 位 置 ID， 换 而 言 
之 ， 就 是 将 父 RDD 中 的 Partition 根据 partitionId 的 顺序 依次 插入 到 子 RDD 中 。 

分 析 完 Spark 中 的 源 代码 ， 下 边 通过 两 个 实例 来 让 大 家 了 解 RDD 罕 依 赖 输出 的 结果 。 

对 于 OneTo0OneDependeney， 采 用 map 操作 进行 实验 ， 实 验 代 码 和 结果 如 下 。 






































def main( args: Array[ String] ) | 

val numl = Array( 100 ,80 ,70 ) 

val rddnuml = sc. parallelize(numl ) 
val mapRdd = rddnuml. map(_ * 2) 
mapRdd. collect( ). foreach( println) 
| 


A 





结果 为 : 200 160 140。 
对 于 RangeDependency， 采 用 union 操作 进行 实验 ， 实 验 代 码 和 结果 如 下 。 








1]. def main( args:Array[ String] ) | 
2 // 创 建 数组 1 
3. val datal = Array("spark" ,"scala" ,"hadoop" ) 








© 
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// 创 建 数组 2 
val data2 = Array( " SPARK" ,"SCALA" ," HADOOP" ) 





val rddl = sc. parallelize( datal ) 
// 将 数组 2 的 数据 形成 RDD2 
val rdd2 = sc. parallelize( data2 ) 
10. /把 RDD1 与 RDD2 union 
11. val unionRdd = rddl. union( rdd2 ) 
12. /将 结果 收集 并 输出 
13. unionRdd. collect( ). foreach( println) 
14. | 











4 
5. 
6. // 将 数组 1 的 数据 形成 RDD1 
7 
8 
9 





结果 为 : spark scala hadoop SPARK SCALA HADOOP。 


宽 依 赖 ( Shuffle Dependency) 


RDD 的 宽 依赖 是 一 种 会 导致 计算 时 产生 Shuffle 操作 的 RDD 操作 ， 用 来 表示 一 个 父 RDD 
的 Partition 都 会 被 多 个 子 RDD 的 Partition 所 使 用 ， 如 图 2-2 中 的 groupByKey 所 示 ， 父 RDD 
有 3 个 Partition ， 每 个 Partition 中 的 数据 会 被 子 RDD 中 的 两 个 Partition 使 用 。 














与 非 协 同 分 区 的 输入 
值 进 行 join 操作 


groupByKey 





图 2-2” 宽 依 赖 关系 图 





有 关 宽 依赖 的 源 代码 位 于 Dependency. scala 文件 的 Shuffle Dependency 方法 ， 第 3 行 产 生 
了 新 的 Shuffleld， 表 明了 宽 依赖 过 程 需 要 涉及 Shuffle 操作 ; 途中 后 续 的 代码 表示 宽 依赖 进行 
时 的 Shuffle 操作 需要 向 shuffleManager 注册 信息 。 


class ShuffleDependency| K:ClassTag,V :ClassTag,C:ClassTag | () 
// 创 建新 的 ShuffleId 
val shuffleld: Int = _rdd. context. newShuffleld( ) 
// 问 shuffleManagerage 注册 Shuffle 
val shuffleHandle :ShuffleHandle = _rdd. context. env. shuffleManager. registerShuffle ( shuffleld,_ 
rdd. partitions. size ,this ) 








eb 全 > 


6. _rdd. sparkContext. cleaner. foreach( _. registerShuffleForCleanup( this) ) 


Spark 中 ， 宽 依赖 关系 很 常见 ， 其 中 较为 经 典 的 操作 为 GroupByKey (将 输入 的 key - value 


第 2 言 ， CU ET 





类 型 的 数据 进行 分 组 ， 对 于 相同 Key 的 value 值 进 行 合 并 ， 生 成 一 个 Tuple2 数组 ， 如 图 2-3 
所 示 )， 具 体 代 码 和 操作 结果 如 下 所 示 ， 这 里 输入 5 个 Tuple2 类 型 的 数据 ， 通 过 运行 产生 3 
个 Tuple2 数据 。 


1. def main( args:Array[ String| ) | 

9 // 设 置 输入 的 Tuple2 数组 

3. val data = Array( Tuple2( "spark" ,100),Tuple2( "spark" ,95 ) ， 
4. Tuple2("hadoop" ,99) ,Tuple2(" hadoop" ,80),Tuple2( "scala" ,75 ) ) 
5. /将 数组 内 容 转化 为 RDD 

6. val rdd = sc. parallelize( data) 

了 9 // 对 RDD 进行 groupByKey 操作 

8. val rddGrouped =rdd. groupByKey( ) 

9 // 输 出 结果 

10. rddGrouped. collect. foreach( println) 

11. 


操作 结果 如 图 2-3 所 示 。 





(scala, CompactBuffer (75)) 
(spark, CompactBuffer (100, 95)) 
(hadoop, CompactBuffer (99, 80)) 














图 2-3 GroupByKey 结果 


本 节 内 容 主 要 讲解 关于 RDD 依赖 关系 的 基本 定义 ， 并 从 源 代码 层面 讲解 依赖 关系 的 真 
正 实现 方式 ， 但 是 由 于 整个 Spark 计算 都 是 基于 RDD 的 计算 ， 对 于 RDD 之 间 的 依赖 关系 的 
深刻 理解 是 很 重要 的 一 部 分 ,希望 读者 可 以 仔细 阅读 Dependency. scala 类 下 的 源 代码 ， 并 且 
多 做 几 个 具体 的 案例 (推荐 在 Spark - Shell 中 进行 ) ， 以 加 深 对 依赖 关系 的 理解 。 




















有 向 无 环 图 ( Directed Acyclic Graph，DAG ) 
光 允 什么 是 DAG ) 





在 图 论 中 ， 如 果 一 个 有 向 图 无 法 从 任意 顶点 出 发 经 过 若干 条 边 回 到 该 点 ， 则 这 个 图 就 是 
一 个 有 向 无 环 图 (DAG 图 )。 而 在 Spark 中 由 于 计算 过 程 很 多 时 会 有 先后 顺序 ， 受制 于 某 些 
任务 必须 比 另 一 些 任务 较 早 执行 的 限制 ， 必 须 对 任务 进行 排队 ， 形 成 一 个 队列 的 任务 集合 ， 
这 个 队列 的 任务 集合 就 是 DAG 图 。 每 一 个 顶点 就 是 一 个 任务 ， 每 一 条 边 代表 一 种 限制 约束 
(Spark 中 的 依赖 关系 ) 。 

通过 DAG，Spark 可 以 对 计算 的 流程 进行 优化 ， 对 于 数据 处 理 可 以 对 单一 结 点 上 进行 的 
计算 操作 合并 ， 并 且 计算 中 间 数 据 通过 内 存 进 行 高 效 读 写 ， 对 于 数据 处 理 需 要 涉及 Shuffle 
操作 的 步 又 进行 Stage 划分 ， 从 而 使 计算 资源 的 利用 更 加 高 效 、 合 理 , 减少 计算 资源 的 等 待 
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过 程 ， 减 少 计算 中 间 数 据 读 写 产 生 的 时 间 浪 费 (基于 内 存 的 高 效 读 写 ) 。 





DAG 的 生成 机 制 ) 


Spark 中 的 DAG 生成 过 程 的 重点 便 是 对 于 Stage 的 划分 ， 其 划分 依据 是 RDD 的 依赖 关 
系 ， 对 于 不 同 的 依赖 关系 高 层 调度 器 会 进行 不 同 的 处 理 。 对 于 窄 依赖 ，RDD 之 间 的 数据 不 
需要 进行 Shuffle， se a a 所 以 窗 依 赖 在 Spark 中 被 
划分 为 同一 个 Stage; 对 于 宽 依赖 ， 由 于 Shuftle 的 存在 ， 必 须 等 到 父 RDD 的 Shuffle 处 理 完 
成 后 才能 开始 接 下 来 的 计算 ， 所 以 会 在 此 处 进行 Stage 的 加 分 

在 Spark 中 DAG 生成 的 流程 关键 在 于 回溯 ， 在 程序 提交 后 ， 高 层 调度 器 将 所 有 的 RDD 
看 成 是 一 个 Stage， 然 后 对 此 Stage 进行 从 后 往 前 的 回溯 ， 遇 到 Shuffle 就 断 开 ， 遇 到 窦 依赖 
则 归并 到 同一 个 Stage。 等 到 所 有 的 步 又 回溯 完成 后 ， 便 生成 了 一 个 DAG 图 。 

DAG 生成 的 相关 源 代码 位 于 Spark 的 DAGSchueduler scala 的 getParentStages 方法 中 ， 方 
法 具体 内 容 如 下 所 示 ， 源 代码 中 通过 for 循环 遍历 RDD 依赖 关系 ， 并 对 其 进行 模式 匹配 ， 如 
果 关 系 为 Shuffle Dependency， 则 将 其 加 入 到 ShuffleMapStage 中 。 




















1. private def getParentStages(rdd:RDD| _| ,firsUyobId:Int) :List[ Stage] = | 
2 val parents = new HashSet| Stage | 

3 val visited = new HashSet| RDD[ _|]] 

4 val waitingForVisit = new Stack[ RDD[ _|]] 

5. // 定 义 visit 函数 

6 def visit(r:RDD[ _|])| 

7 // 判 断 该 RDD 是 否 被 访问 

8 if (lvisited(r) ) | 

9 // 如 果 未 被 访问 , 则 再 加 入 到 visited 数据 结构 中 




















10. visited + =r 

11. // 将 该 RDD 的 依赖 关系 进行 循环 遍历 

六 for (dep < —r. dependencies ) | 

13. // 对 依赖 关系 进行 模式 匹配 

14. dep match | 

ls // 如 果 是 宽 依 赖 , 则 形成 一 个 新 的 shuffleMapStage 
16. case shufDep:ShuffleDependency[ _,_,_| => 

7 parents + = getShuffleMapStage( shufDep ,firstJobId ) 
18. // 如 果 不 是 , 则 将 此 RDD 放 和 人 堆栈 

19. case _=> 

20. waitingForVisit. push( dep. rdd) 

21. | 

32 | 

2 | 

24. } 





25. /如 果 此 RDD 已 被 访问 , 则 直接 放 入 堆栈 





20. 
2 
28. 
293 
30. 
31. 
3 
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waitingForVisit. push( rdd) 
while (waitingForVisit. nonEmpty ) | 
visit( waitingForVisit. pop( ) ) 
] © 
// 返 回 stage 的 列表 


parents. toList 


_DAG 的 逻辑 视图 





本 节 主 要 通过 一 个 简单 计数 案例 ， 从 中 讲解 DAG 具体 生成 的 流程 和 关系 。 示 例 代码 如 下 。 


ST A SA 


一 一 一 一 
上 mn” S 





val conf = new SparkConf( )//create SparkConf 

conf. setAppName("Wow,My First Spark App" )//set app name 

conf setMaster(" local" )//run local 

val sc = new SparkContext( conf) 

val lines = sc. textFile(" C://Users//feng/ /ldeaProjects// WordCount//sre//SparkText. txt" ,1) 
// 操 作 1 flatMap 由 lines 通过 flatMap 形成 新 的 MapPartitionRDD 

val words = lines. flatMap | lines => lines. split(" ") | 

// 操 作 2 map 由 word 通过 Map 操作 形成 新 的 MapPartitionRDD 

val pairs = words. map | word => (word ,1 ) | 


// 操 作 3 reduceByKey( 包含 2 步 reduce) 











. // 此 步骤 生成 MapPartitionRDD 和 ShuffleRDD 


val WordCounts = pairs. reduceByKey( _+_) 
WordCounts. collect. foreach( println) 
sc. stop( ) 





在 程序 正式 运行 前 ，Spark 的 DAG 调度 器 会 将 整个 流程 设 定 为 一 个 Stage ， 此 Stage 包含 
3 个 操作 和 4 个 RDD ， 分 别 为 MapPartitionRDD ( 读 取 文件 数据 时 )、 MapPartitionRDD (flat- 


Map 操作 ) 、 


MapPartitionRDD (map 操作 ) 、MapPartitionRDD (reduceByKey 的 local 段 的 操 


作 ) 和 ShuffleRDD (reduceByKeyshuffle 操作 ) 。 


1) 回 漳 整 


个 流程 ， 在 shuffleRDD 与 MapPartitionRDD (reduceByKey 的 local 段 的 操作 ) 


中 存在 Shuffle 操作 ， 整 个 RDD 先 在 此 切 开 ， 形 成 两 个 Stage。 
2) 继续 向 前 回 湖 ，MapPartitionRDD (reduceByKey 的 local 段 的 操作 ) 与 MapParti- 
tionRDD (map 操作 ) 中 间 不 存在 Shuffle 操作 ( 即 两 个 RDD 的 依赖 关系 为 窄 依赖 ) ， 归 为 同 


一 个 广 Stage。 


3) 继续 





回 湖 ， 发 现 之 前 的 所 有 RDD 之 间 都 不 存在 Shuffle， 应 归 为 同一 个 stage。 


4) 回溯 完成 ， 形 成 DAG， 由 两 个 Stage 构成 。 


。 第 一 个 Stage 由 MapPartitionRDD ( 读 取 文件 数据 时 ) 、MapPartitionRDD (flatMap 操 


作 )、 





MapPartitionRDD (map 操作 ) 和 MapPartitionRDD (reduceByKey 的 local 段 的 操 
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作 构 成 ， 如 图 2-4 所 示 。 
e 第 二 个 Stage 由 ShuffleRDD (reduceByKey shuffle 操作 ) 构成 ， 如 图 2-5 所 示 。 
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攻 且 RDD 内 部 的 计算 机 制 


本 节 开 始 讲解 RDD 运算 基本 单位 Task， 目 的 是 让 读者 可 以 从 根本 上 了 解 sparkRDD 计算 
是 如 何 进 行 的 ， 计 算 流 程 是 如 何 处 理 的 等 内 容 。 


2 RDD 的 计算 任务 (Task) 


1. 什么 是 Task 

Task 是 计算 运行 在 集群 上 的 基本 计算 的 单位 。 一 个 Task 负责 处 理 RDD 的 一 个 Partition ， 
一 个 RDD 的 多 个 Patition 会 分 别 由 不 同 的 Task 去 处 理 ， 通 过 之 前 对 于 RDD 的 窗 依 赖 关 系 的 
讲解 可 以 发 现 ， 在 RDD 的 窗 依 赖 中 ， 子 RDD 中 Partition 的 个 数 基本 都 大 于 等 于 父 RDD 中 
Partition 的 个 数 ， 所 以 Spark 计算 中 对 于 每 一 个 Stage 分 配 的 Task 的 数目 是 基于 该 Stage 中 最 
后 一 个 RDD 的 Partition 个 数 来 决定 的 。 最 后 一 个 RDD 如 果 有 100 个 Partition， 则 Spark 对 这 
个 Stage 分 配 100 个 Task。 

Task 运行 于 Executor 之 上 ， 而 Execuotr 位 于 CoarseGrainedExecutorBackend (JVM 进 
程 ) 中 。 

2. Task 的 分 类 

Spark Job 中 ， 根 据 Task 所 处 Stage 的 位 置 可 将 Task 分 为 两 类 ,第 一 类 为 shuf- 
fleMapTask， 指 Task 所 处 的 Stage 不 是 最 后 一 个 Stage， 也 就 是 Stage 的 计算 结果 还 没有 输出 ， 
而 是 通过 Shuffle 交 给 下 一 个 Stage 使 用 ; 第 二 类 为 resultTask ， 指 Task 所 处 的 Stage 是 DAG 
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中 最 后 一 个 Stage， 也 就 是 Stage 计算 结果 需要 进行 输出 等 操作 ， 计 算 到 此 为 止 已 经 结束 。 简 
单 地 说 ， Spark Job 中 除了 最 后 一 个 Stage 的 Task 称 为 resultTask 外 ， 其 他 所 有 的 Task 都 称 为 
shuffleMapTask。 





RDD 的 计算 过 程 > 


Spark 中 的 Job 是 由 具体 的 Task 构成 的 ， 基 于 Spark 程序 内 部 的 调度 模式 ， 根 据 宽 依赖 
的 关系 划分 不 同 的 Stage， 最 后 一 个 Stage 依赖 倒数 第 二 个 Stage 等 ， 从 最 后 一 个 Stage 获取 结 
果 ; 在 Stage 内 部 有 一 系列 的 任务 ， 这 些 任务 被 提交 到 集群 上 的 计算 结 点 进行 计算 ， 计 算 结 
点 执行 计算 逻辑 时 ， 复 用 位 于 Executor 中 的 线程 池 中 的 线程 ， 线 程 中 运行 的 任务 是 调用 具体 
Task 的 run 方法 进行 计算 ， 此 时 ， 如 果 调 用 具体 Task 的 run 方法 ， 需 要 考虑 不 同 Stage 内 部 
具体 Task 的 类 型 ， Spark 规定 最 后 一 个 Stage 中 的 Task 的 类 型 称 为 resultTask， 因 为 需要 获取 
最 后 的 结果 ， 前 面 所 有 Stage 的 Task 都 是 shuffleMapTask 。 

RDD 在 进行 计算 前 ，Driver 给 Executor 发 送 消息 ， 让 Executor 启动 Task， 在 Executor 成 
功 启动 Task 后 ， 通 过 消息 机 制 汇 报 启动 成 功 信息 给 Driver。 如 下 图 2-6 所 示 。 

执行 器 


DAGScheduler TaskRunner 在 ThreadPool 运 行 具体 
Driver 发 送 LaunchTask 的 Task: 


。 向 Driver 汇 报 状 态 
。 反 序列 化 ， Task 依赖 等 
。 通 过 网 络 来 获取 需要 的 文件 、 


Jar 























ShuffleMapTask: a A 
MapOutput 。compute 计 算 Partition 运行 Thread 的 run 方 法 ， 导 致 


age 。shuffleWriter 写 人 具体 文件 Task 的 抽象 方法 runTask 被 调用 执 
。 将 MapStatus 发 送 给 Driver 行 具体 的 业务 逻辑 处 理 ， 
MapOutputTracker ShuffleMapTask 。 在 Task 的 runTask 内 部 会 调用 

RDD 的 iterator0 方 法 ， 该 方法 
ResultTask 就 是 我 们 针对 当前 Task 所 对 应 

ResultTask: 的 Partition 进 行 计算 的 关键 之 
根据 前 面 Stage 的 执行 结果 进行 所 在 

shuffle 后 产生 整个 job 最 后 的 结果 。 在 处 理 的 处 理 内 部 会 迭代 
Partition 的 元 素 并 交 给 我 们 
自 定义 的 function 进 行 处 理 















































图 2-6 RDD 的 计算 过 程 

有 具体 操作 如 下 。 

1) Driver 中 的 CoarseGrainedSchedulerBackend 给 CoarseGrainedExecutorBackend 发 送 
LaunchTask 消息 。 

2) 首先 反 序 列 化 TaskDescription (下 述 第 11 行 )。 





1. ， override def receive:PartialFunction[ Any,Unit] = | 
多 case LaunchTask( data) => 

4. ”如 果 无 可 用 于 计算 的 Executor, 则 输出 错误 日 志 
5 **/ 
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if (executor == null) | 


logError( " Received LaunchTask command but executor was null" ) 
System. exit( 1) 
| else | 
// 反 序列 化 TaskDescription 
val taskDesc = ser deserialize[ TaskDescription | ( data. value ) 
// 写 入 日 志 
logInfo( " Got assigned task " +taskDesc. taskld) 


. // 调 用 executor 的 launchTask ,分配 线程 给 Task 


executor. launchTask( this ,taskId = taskDesc. taskId ,attemptNumber 


= taskDesc. attemptNumber,taskDesc. name ,taskDesc. serializedTask ) 





3 ) Executor 会 通过 LaunchTask 来 执行 Task (上 述 第 15 行 )。 
4) Executor 的 launchTask 方法 中 通过 taskRunner 对 象 在 threadPool 运行 具体 的 Task (下 





述 代 码 第 9 行 )。 
1. // 人 代码 来 源 Executor. scala 
2. def launchTask( 
3) context :ExecutorBackend ， 
4 taskId: Long， 
5. attemptNumber: Int, 
6 taskName: String, 
7 serializedTask: ByteBuffer) : Unit = | 
8 // 调 用 TaskRunner 句柄 创建 TaskRunner 对 象 
9 val tr = new TaskRunner ( context, taskld = taskId，attemptNumber = attemptNumber， 
taskName ， 
10. serializedTask ) 
11. // 将 创建 的 taskRunner 对 象 放 入 即将 进行 的 堆栈 中 
U2 runningTasks. put( taskld , tr) 
lS // 从 线程 池 中 分 配 一 条 线程 给 taskRunner 
14. threadPool. execute( tr) 
15. | 


在 taskRunner 的 run 方法 中 首先 会 通过 statusUpdate 给 Driver 发 信息 汇报 自己 的 状态 ， 
说 明 自 己 是 running 状态 (下 述 代 码 第 9 行 , 第 22 行 )。 

同时 TaskRunner 内 部 会 做 一 些 准备 工作 ,例如 反 序 列 化 Task 的 依赖 (下 述 代码 第 13 
行 )， 通 过 网 络 获 取 需 要 的 文件 Jar 等 (下 述 代码 第 13 行 ) 。 

之 后 反 序列 化 Task 本 身 (下 述 代码 第 15 行 ) 。 








1. 
2 








// 代 码 来 源 Executor. scala 


override def run( ) :Unit = | 
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3 val taskMemoryManager = new TaskMemoryManager( env. memoryManager,taskId ) 

4. val deserializeStartTime = System. currentTimeMillis( ) 

5. Thread. currentThread. setContextClassLoader( replClassLoader) 

6. val ser = env. closureSerializer newInstance( ) O) 

7. logInfo(s"Running $ taskName( TID $ taskld)") 

8 // 通 过 executorBackend 的 statusUpdate 方法 ,给 Driver 发 送 Task 的 Running 状态 ,第 18 行 
引用 了 statusUpdate 方法 

9. execBackend. statusUpdate(taskId ,TaskState. RUNNING, EMPTY_BYTE_BUFFER) 

10. var taskStart:Long = 0 

11. startCCTime = computeTotalGcTime( ) 

12. try | 

13. val (taskFiles,taskJars,taskBytes) = Task. deserializeWithDepaaendencies( serializedTask) 

14. updateDependencies( taskFiles, taskJars) 

15. task = ser. deserialize[ Task[ Any | | (taskBytes ,Thread. currentThread. getContextClassLoader) 

16. task. setTaskMemoryManager( task MemoryManager) 


18. /A 下 述 代 码 来 源 .CoarseGradeExecutorBackend. scala 
19. override def statusUpdate(taskId :Long ,state:TaskState ,data:ByteBuffer) | 


20. val msg = StatusUpdate( executorld, taskld ,state ,data) 

2 driver match | 

2 case Some( driverRef) => driverRef send( msg) 

2 case None =>logWarning( s" Drop $ msg because has not yet connected to driver" ) 
24. | 

2 } 

26. | 

270 

















5) 调用 反 序列 化 后 的 Task. run 方法 来 执行 任务 ， 并 获得 执行 结果 (下 述 代 码 第 5 行 ) 。 


1. /Task 计算 开始 的 时 间 

2. taskStart = System. currentTimeMillis( ) 

3 var threwException = true 

4 val (value,accumUpdates) = try | 

5, // 运 行 Task 的 run 方法 

6 val res = task. run( 

7 taskAttemptld = taskld, 

8 attemptNumber = attemptNumber, 
9 


metricsSystem = env. metricsSystem ) 


10. threwException = false 
11. res 
2 | finally | 


i /计算 完成 后 清理 内 存 , 并 检查 是 否 有 内 存 溢出 
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14. val freedMemory = task MemoryManager. cleanUpAllAllocatedMemory( ) 

15. if(freedMemory > 0)| 

16. val erraMsg = s" Managed memory leak daetected; size = $ freedMemory bytes ,TID = 
$ taskId" 

17. if (conf. getBoolean( " spark. unsafe. exceptionOnMemoryLeak" ,false) && |threwEx- 
ception ) | 

18. throw newSparkException( errMsg) 

19. | else | 

20. logError( errMsg) 

2 } 

22. | 

23. | 

24. 人 计算 完成 的 时 间 

2 val taskFinish = System. currentTimeMillis( ) 





通过 查看 task. run 方法 的 源 代码 可 以 发 现 ，run 方法 调用 了 runTask 的 方法 ， 而 runTask 
方法 是 一 个 抽象 方法 ，runTask 方法 内 部 会 调用 RDD 的 iterator( ) 方 法 ， 该 方法 就 是 针对 当前 
Task 所 对 应 的 Partition 进行 计算 的 关键 所 在 ， 在 Executor 的 内 部 会 迭代 Partition 的 元 素 并 交 
给 用 户 自 定义 的 Function 进行 处 理 。 














1. /A// 代 码 来 源 .Task. scala 

2 

3 (runTask( context ) , context. collectAccumulators( ) ) 
4 | 








Task 有 两 个 子 类 ， 分 别 是 ShuffleMapTask 和 ResultTask ， 接 下 来 分 别 对 两 者 进行 讲解 : 
GD ShuffleMapTask 。 








1. override def runTask( context:TaskContext) :MapStatus = | 

2 //Deserialize the RDD using the broadcast variable. 

3 val deserializeStartTime = System. currentTimeMillis( ) 

4 // 创 建 序列 化 带 

S$ val ser = SparkEnv. get. closureSerializer. newInstance( ) 

6 // 反 序列 化 出 RDD 和 依赖 关系 

7 val (rdd,dep) = ser deserialize[ ( RDD|[ _| ,ShuffleDependency[_,_,_])]( 

8 ByteBuffer. wrap(taskBinary. value ) ,Thread. currentThread. getContextClassLoader) 
9 /ARDD 反 序列 化 的 时 间 

10. _executorDeserializeTime = System. currentTimeMillis( ) - deserializeStartTime 
11. metrics = Some( context. taskMetrics) 

12. // 创 建 shuffle 的 writer 对 象 , 用 来 将 计算 结果 写 入 shuffle 管理 需 

13. var writer: ShuffleWriter[ Any,Any] = null 

14. try | 
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Ws // 实 例 化 shuffleManager 

16. val manager = SparkEnv. get. shuffleManager 

17. // 对 writer 对 象 赋值 

18. writer = manager. getWriter[ Any, Any | ( dep. shuffleHandle ,partitionId ,context ) O) 

19. // 将 计算 结果 通过 writer 对 象 的 write 方法 写 入 shuffle 的 过 程 

20. writer. write ( rdd. iterator ( partition , context ) . asInstanceOf| Iterator[ _ < : Product2[ Any, 
Any| | ]) 

2 writer. stop( success = true). get 

2 | catch | 

239 case e: 上 Exception => 

24. try | 

23. if (writer {= null) | 

26. writer. stop( success = false ) 

27. | 

28. |} catch | 

29. case e: 上 Exception => 

30. log. debug( " Could not stop writer" ,e) 

Sl 

3 throw e 

33. } 

34. } 


首先 ，ShuffleMapTask 会 反 序列 化 RDD 及 其 依赖 关系 (上述 代码 第 7 行 )。 
(上 述 代 码 第 20 行 ) 通过 调用 RDD 的 iterator 方法 进行 计算 ， 而 iterator 方法 中 进行 的 最 
终 运算 的 方法 是 compute( ) 。 








1. /A// 代 码 来 源 .RDD. scala 
2. final def iterator( split: Partition, context:TaskContext) :Iterator[ 了 了] = | 
3 // 判 断 此 RDD 的 持久 化 等 级 是 否 为 NONE( 不 进行 持久 化 ) 
4 if (storageLevel != StorageLevel. NONE)| 

于 // 如 果 持 久 化 等 级 不 为 空 , 则 先 去 缓存 管理 器 中 查看 是 否 有 缓存 , 若 无 再 进行 计算 
6 

% 

8 

9 














SparkEnv. get. cacheManager. getOrCompute( this ,split , context , storageLevel ) 
| else | 
// 如 果 持 久 化 等 级 为 NONE, 则 直接 进行 计算 
ld computeOrReadCheckpoint( split ,context ) 
10. } 
11. } 
12. /代码 来 源 :RDD. scala 
13. private[ spark | def computeOrReadCheckpoint ( split: Partition, context: TaskContext ) : Iterator 

i 

14. | 
15. /判断 该 RDD 是 否 进行 过 checkpoint 
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16. if (isCheckpointed AndMaterialized ) | 
17.// 从 上 次 检查 点 开始 进行 计算 

18. firstParent| T ]. iterator( split ,context ) 
19. | else | 

20. /直接 进行 计算 

2 compute( split ,context ) 

22 } 

2 


24. RDD 的 子 类 MapPartitionsRDD 代码 
25. private| spark | class MapPartitionsRDD| U.ClassTag,T:ClassTag | ( 


26. prev: RDDIL T]， 

27 f: (TaskContext, Int, Iterator[ T] ) => lterator[ U], //(TaskContext, partition index ,itera- 
tor) 

28. preservesPartitioning :Boolean = false ) 


29, extends RDDI| U | (prev) | 


30. override val partitioner = if( preservesPartitioning ) firstParent[ T |. partitioner else None 
3 override def getPartitions: Array[ Partition | = firstParent[ T ]. partitions 

3 override def compute( split: Partition, context: TaskContext) : Iterator[ U | = 

33. f( context, split. index ,firstParent[ T ]. iterator( split, context ) ) 

34. | 


而 RDD 的 compute 方法 是 一 个 抽象 方法 ， 每 个 RDD 都 需要 重 写 上 次 方法 。 
此 时 选择 查看 MapPartitionsRDD 已 经 实现 的 compute 方法 ， 可 以 发 现 compute 方法 是 通 
过 f 方 法 实现 的 ， 而 f 方 法 就 是 在 创建 MapPartitionsRDD 时 输入 的 操作 函数 。 














日 注意: 通过 迭代 器 的 不 断 重 加 ， 将 每 个 RDD 的 小 函数 合并 成 一 个 大 的 函数 流 。 





然后 在 计算 具体 的 Partition 之 后 ， 会 通过 shuffleManager 获得 的 shuffleWriter 把 当前 Task 
计算 的 结果 根据 具体 的 shuffleManager 实现 写 入 到 具体 的 文件 ， 操 作 完 成 之 后 会 把 MapStatus 
发 送 给 Driver 端的 DAGScheduler 的 MapOutputTracker。 

@) ResultTask。Driver 端的 DAGSchueduler 的 MapOutputTracker 把 shuffleMapTask 执行 的 
结果 交 给 ResultTask ，ResultTask 根据 前 面 Stage 的 执行 结果 进行 Shuffle 后 产生 整个 Job 最 后 
的 结 











override def runTask( context: TaskContext) :U = | 
//Deserialize the RDD and the func using the broadcast variables. 
val deserializeStartTime = System. currentTimeMillis( ) 
// 创 建 序列 化 需 


1 
2 
3 
4 
S3 val ser = SparkEnv. get. closureSerializer. newInstance( ) 
6 
% 
8 





// 反 序列 RDD 和 func 处 理 函 数 
val (rdd ,func) = ser. deserialize[ ( RDD| T|, (TaskContext, Iterator[ T] ) => U) ]( 
ByteBuffer. wrap(taskBinary. value ) ,Thread. currentThread. getContextClassLoader ) 
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9. _executorDeserializeTime = System. currentTimeMillis( ) - deserializeStartTime 

10. 

11. metrics = Some( context. taskMetrics ) 四 
jl func( context ,rdd. iterator( partition ,context ) ) O) 

13. | 


ResultTask 的 runTask 方法 中 (第 12 行 ) 反 序 列 化 生成 func 哨 数 ， 最 后 通过 func 也 数 
计算 出 最 终结 
6) 上 述 计算 完成 后 ， 对 数据 进行 传输 。 





| Section | 


RDD 中 缓存 的 适用 场景 和 工作 机 制 











小 虽 昌 缓存 的 使 用 SS 


Spark 的 缓存 通过 RDD 的 cache 方法 实现 ，Cache 方法 是 Persist 持久 化 时 Storagelevel 参 
数 默认 设置 为 MEMORY_ONLY。 在 调用 Cache 方法 的 时 候 ，Cache 方法 先 执行 不 带 参 数 的 
Persist 方法 ， 而 无 参数 的 Persist 方法 在 实现 时 会 调用 默认 参数 为 MEMORY_ONLY 的 Persist 
方法 ， 在 这 个 方法 中 ， 首 先 设置 RDD 的 Storagelevel， 然 后 在 sparkContext 中 进行 标记 ， 而 且 
Storagelevel 只 能 被 设置 一 次 ， 如 果 Storagelevel 从 None 修改 为 一 个 值 以 后 ， 就 不 能 再 修改 。 
在 RDD 的 核心 计算 函数 迭代 器 函数 中 ， 当 Task 运行 的 时 候 会 调用 RDD 的 Compute 方法 进 
行 计 算 ， 而 Compute 方法 会 调用 Iterator 方法 ， 如 果 StorageLevel 不 是 NONE， 那 RDD 就 通过 
CacheManager 的 getOrCompute 来 调用 获取 缓存 数据 或 者 重新 计算 。 








final def iterator( split: Partition, context: TaskContext) : Iterator[ T | = | 

if (storageLevel!= StorageLevel. NONE) | 

SparkEnv. get cache Manager. getOrCompute( this ,split, context , storageLevel ) 
| else | 

computeOrReadCheckpoint( split ,context ) 
| 

| 


SN A er 


对 于 RDD 的 缓存 触发 ， 本 节 通 过 一 个 基于 spark - shell 环境 下 的 WordCount 实例 进行 说 
明 。 实 例 代码 〈 无 缓存 情况 ) 如 图 2-7 所 示 ， 运 行 结果 如 图 2-8 所 示 ， 整 个 任务 运行 时 间 
超过 40s， 亦 即 如 果 整 个 任务 的 计算 数据 产生 丢失 ， 再 次 计算 需要 花费 40 s 的 时 间 ， 而 基于 
内 存 的 数据 的 丢失 十 分 常见 ， 对 此 ，Spark 开发 了 自 有 的 持久 化 机 制 Persist， 而 默认 的 Per- 
sist 机 制 就 是 Cache ， 也 就 是 通过 缓存 实现 的 。 





内 核 机 制 解析 及 性 能 调 优 


scala> val wordcount = sc.textFile("/library/wordcount/input/licenses").flatMa 
p(_.split(" ")).map(word=>(word,1)).reduceByKey(_+ ).filter(pair=>pair. 2>20).c 
CE) | 








ER 








2-7 无 缓存 的 WordCount 代码 





=| KR qVEe 日 UNIBPLELESU U 
16/02/12 18:44:20 INF0 scheduler.DAGScheduler: ResultStage 1 (collect at <conso 
Le>:27) finished in 0.833 5 


16/02/12 18:44:20 INF0 scheduler.DAGScheduler: Job 0 finished: collect at <cons 
OLe>:27，took 40.526622 5S 














图 2-8 无 缓存 代码 执行 耗 时 





之 后 通过 对 代码 进行 改进 ， 在 计算 完成 后 先进 行 缓存 ， 然 后 对 缓存 结果 进行 收集 和 显 
示 ， 可 以 发 现 ， 从 缓存 中 收集 数据 并 显示 花费 的 时 间 为 1.8s， 从 容错 角度 讲 ，1. 8 s 的 时 间 
对 比 之 前 重新 计算 需要 40 s 的 时 间 来 说 , 已 经 大 大 降低 了 计算 资源 的 浪费 。 

图 2-9 ~ 图 2-11 所 示 为 对 代码 进行 改进 ， 使 之 先进 行 缓存 后 再 进行 计算 ， 并 显示 缓存 
后 的 计算 时 间 等 信息 。 








scala> val wordcount caches = sc,.textFile("/\library/wordcount/input/licenses") 


.flatMap(_.split(" ")).map(word=>(word,1)).reduceByKey( + ).filter(pair=>pair,_ 
2>20) .cache() 目 








器 








2-9 对 WordCount 结果 进行 缓存 





scala> wordcount caches.collect.foreach (println)|| 





图 2-10 输出 缓存 后 的 结果 


16/02/12 18:46:53 INF0 scheduler.DAGScheduler: ResultStage 5 (collect at <conso 
Le>:30) finished in 0.664 s 

16/02/12 18:46:53 INF0 scheduler.DAGScheduler: Job 2 finished: collect at <cons 
ole>:30, took 1.832612 s 





图 2-11 缓存 获取 计算 数据 耗 时 





J 缓存 的 适用 场景 


绥 存 并 不 是 每 一 个 步骤 都 需要 使 用 的 ， 虽然 说 缓存 可 以 放置 在 内 存 中 (也 有 可 能 在 磁 
盘 中 ) ， 读 写 速度 极 快 ， 但 是 ， 大 量 的 缓存 读 写 也 会 对 整个 集群 的 计算 性 能 造成 影响 ， 如 何 
更 好 地 设置 缓存 对 于 一 个 集群 的 计算 性 能 的 提升 也 起 着 非常 重要 的 作用 。 

以 下 是 几 种 比较 适合 使 用 缓存 的 情况 。 

1) 获取 大 量 的 数据 之 后 。 比 如 来 自从 外 部 数据 源 (HDFS、HIVE 和 HBASE 等 ) ， 或 者 
来 自 上 一 个 Stage， 如 果 数 据 丢 失 需 要 进行 重新 获取 或 计算 。 

2) 进行 一 个 非常 长 的 计算 链条 。 如 果 在 长 计算 链条 中 某 一 步骤 出 现 数据 丢失 ， 则 需要 
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重新 计算 整个 链条 ， 例 如 ， 一 个 1000 步骤 计算 的 计算 链条 ， 在 第 900 步 设 置 缓存 ， 则 如 果 
在 901 步 出 现 错误 ， 则 不 需要 重新 计算 前 900 个 步 又 ,直接 从 缓存 点 (第 900 步 ) 的 缓存 开 
始 下 一 步 计算 。 
3) 革 个 步 又 计 算 特 别 耗 时 。 此 步 又 计算 完成 后 进行 缓存 ， 以 免 后 续 的 步骤 出 现 错误 需 人) 
要 再 次 进行 长 时 间 的 计算 。 
4) 进行 Checkpoint 之 前 ,一 般 也 会 进行 缓存 。 














>、 


缓存 工作 机 制 解析 时 





1. 缓存 的 工作 机 制 

Spark 中 对 于 缓存 机 制 的 另外 一 个 说 法 为 持久 化 ， 可 以 用 Persist 表示 ,通常 Spark 中 用 
persist( ) 或 cache( ) 方 法 来 标记 一 个 要 被 持久 化 的 RDD ， 然 后 这 个 RDD 一 旦 首次 被 一 个 动作 
(Action) 触发 计算 ， 它 将 会 被 保留 在 计算 结 点 的 内 存 中 并 重用 。 而 缓存 作为 一 种 保存 数据 


的 方式 ， 也 会 





出 现 数据 丢失 的 可 能 ， 如 果 RDD 的 任 一 分 区 丢失 了 ， 通 过 使 用 原先 创建 它 的 














转换 操作 ， 它 将 会 被 自动 重 算 (不 需要 全 部 重 算 ， 只 计算 丢失 的 部 分 ) 。 

Spark 中 通过 unpersistRDD( ) 来 删除 绥 存 。 

每 一 个 RDD 都 可 以 用 不 同 的 保存 级 别 进行 保存 ， 从 而 允许 持久 化 数据 集 在 人 硬盘， 或 者 
在 内 存 中 作为 序列 化 的 Java 对 象 (节省 空间 ) ， 其 至 于 跨 结 点 复制 。 这 些 等 级 选择 是 通过 将 
一 个 org. apache. spark. storage. StorageLevel 对 象 传递 给 persist( ) 方 法 来 确定 的 。 

2.Persist 与 Cache 的 区 别 

查看 下 述 代 码 ， 可 以 发 现 cache( ) 方 法 实质 上 是 参数 为 memory_only 的 persist 方法 ， 
为 仅 存 储 在 内 存 中 ， 内 存 中 无 法 储存 的 部 分 则 不 缓存 ， 和 人 二 全 | 和 让 及 人 


的 数据 。 


1 
2 
3 
4. 
3 
0 








// 默 认 的 持久 化 等 级 只 保存 在 内 存 中 
/ ** Persist this RDD with the default storage level( MEMORY_ONLY). */ 
def persist( ) :this. type = persist( StorageLevel. MEMORY_ONLY) 


/ ** Persist this RDD with the default storage level( MEMORY_ONLY). */ 
def cache( ) :this. type = persist( ) 


3. Unpersist 操作 
对 于 清除 缓存 的 操作 ， 源 代码 如 下 所 示 ， 就 是 将 Persist 的 持久 化 级 别 改 为 NONE。 


1 
2 
3 
4. 
S 
6 


/ 米 米 
* Mark the RDD as non - persistent ,and remove all blocks for it 位 om memory and disk. 
六 
* @ param blocking Whether to block until all blocks are deleted. 
* @ return This RDD. 
*/ 
def unpersist( blocking: Boolean = true) :this. type = | 









内 核 机 制 解析 及 性 能 调 优 


8 /输出 日 志 

9. logInfo(" Removing RDD " +id +" from persistence list" ) 
10.  ”// 移 除 已 持久 化 的 数据 

11. sc. unpersistRDD( id ,blocking ) 

12. ”// 设 置 持久 化 等 级 为 NONE 

13. storageLevel = StorageLevel. NONE 

14. this 

lS 





4. 持久 化 的 保存 等 级 StorageLevel 
Spark 中 对 持久 化 等 级 定义 分 为 12 类， 源 代码 内 容 如 下 。 


1. object StorageLevel | 

2 val NONE = newStorageLevel( false ,false , false , false ) 

3 val DISK_ONLY = newStorageLevel( true , false , false , false ) 

4 val DISK_ONLY _2 = newStorageLevel( true ,false ,false , false ,2 ) 

全 val MEMORY_ONLY = newStorageLevel(false,true ,false ,true) 

6 val MEMORY_ONLY _2 = newStorageLevel( false ,true , false ,true ,2) 

7 val MEMORY_ONLY_SER = newStorageLevel( false ,true ,false ,false) 

8 val MEMORY_ONLY_SER_2 = newStorageLevel( false, true, false , false ,2 ) 
9 val MEMORY_AND_DISK = newStorageLevel( true ,true ,false ,true) 

10. val MEMORY_AND_DISK_2 = newStorageLevel( true ,true ,false ,true ,2) 
11. val MEMORY_AND_DISK_SER = newStorageLevel( true ,true ,false , false ) 
2 val MEMORY_AND_DISK_SER 2 = newStorageLevel( true ,true ,false ,false ,2 ) 
13. val OFF_HEAP = newStorageLevel( false , false , true , false ) 

14. | 





























e MEMORY_ONLY 表示 数据 只 存储 在 内 存 中 ， 如 果 不 能 被 内 存 装 下 ， 不 能 装 下 的 那 部 
分 分 区 不 被 缓存 ， 并 在 需要 时 重新 计算 。 此 模式 为 Spark 持久 化 的 默认 模式 。 

e MEMORY_AND_DISK 表示 如 果 RDD 数据 不 能 被 内 存 装 下 ， 则 超出 的 分 区 会 被 保存 在 
硬盘 上 ， 并 在 需要 时 读 取 。 

e MEMORY_ONLY_SER 表示 对 象 正 在 存储 中 (每 一 分 区 占用 一 个 字 节 数组 )， 通 常 来 
说 ， 这 样 对 于 控件 的 利用 率 更 加 高 ， 尤 其 是 在 使 用 fast serizlizer 时 ,但 是 读 取 时 会 比 
较 占 用 CPU。 

e MEMORY__AND_DISK_SER 与 MEMORY_ONLY_SER 类 似 ， 但 是 会 把 超出 内 存 的 分 区 
记录 在 磁盘 。 

e DISK_ONLY 表示 RDD 数据 只 储存 在 磁盘 。 

e MEMORY_ONLY_2 每 一 个 分 区 都 储存 在 两 个 集群 结 点 的 内 存 中 上 。 

e MEMPRY_AND_DISK_2 每 一 个 分 区 都 储存 在 两 个 集群 结 点 的 内 在 和 磁盘 中 。 
































RDD 的 运行 机 制 





RDD 的 检查 点 ( Checkpoint) 的 适用 场景 
Be 和 工作 机 制 攻 


Spark 中 对 于 数据 保存 除了 持久 化 操作 之 外 还 存在 一 种 检查 点 (Checkpoint) 方式 ， 原 
在 于 缓存 的 方式 虽然 也 可 以 以 文件 形式 保存 在 磁盘 中 ， 但 是 磁盘 会 出 现 损坏 ， 文 件 也 会 出 
现 丢 失 。 对 于 此 类 危险 ，Hadoop 的 HDFS 多 备份 机 制 起 到 了 很 好 的 容错 能 力 ，Spark 的 外 部 
数据 源 可 以 是 HDFS， 而 HDFS 对 于 文件 的 保存 容错 能 力 又 很 强大 ， 便 出 现 了 Checkpoint 机 
制 ，Checkpoint 可 以 将 保存 的 数据 以 文件 的 方式 保存 在 HDFS 上 ， 借 用 HDFS 强大 的 文件 容 
错 能 力 ， 从 而 降低 数据 被 破坏 或 者 丢失 的 风险 。 


2. S$. | Checkpoint 的 触发 


对 于 Checkpoint， 本 节 依 旧 通 过 spark - shell 中 的 WordCount 实例 进行 解释 。 

对 要 进行 Checkpoint 的 数据 先进 行 缓存 〈( 见 图 2-12) ， 之 后 再 进行 Checkpoint 操作 ( 见 
图 2-13) ， 最 后 对 Checkpoint 后 的 对 象 进行 收集 和 输出 ( 见 图 2-14) 。 同 时 ， 通 过 查看 HDFS 
上 的 文件 ， 可 以 找到 进行 Checkpoint 后 保存 的 文件 〈 见 图 2-15) ， 至 此 完成 一 个 最 简单 的 
Checkpoint 实例 。 





scala> val wordcount= sc.textFile("/library/wordcount/input/licenses").flatMap( 





ErpLlittr Eap Dd On Bed EK 二 le cache 








图 2-12 ”缓存 数据 


scala> wordcount .checkpoint 国 


图 2-13 ”进行 checkpoint 操作 




















scala> wordcount .fiLter(pair=>pair._ 2>20) .coLLect().foreach(printtn) 国 





图 2-14 筛选 checkpoint 数据 后 输出 























lbrary/sparkCheckPoint/29e37500-f88d-4e43-8a8e-1575fded3817 Go! 
Permission OwnNner Group Size Replication Block Size Name 
drwxr-xr-x root supergroup oOB 0 OB rdd-19 
drwxr-xr-x root supergroup oOB OD OB rdd-31 
drwxr-xr-x root supergroup oOB 0 OB rdd-38 
图 2-15 ”Checkpoint 保存 在 HDFS 的 文件 















内 核 机 制 解析 及 性 能 调 优 


Checkpoint 的 适用 场景 





缓存 的 使 用 虽然 广泛 ,但 是 对 于 很 多 的 数据 分 析 算 法 ,使 用 者 需要 更 加 安全 的 数据 缓存 
机 制 ， 以 最 大 程度 地 确保 数据 的 安全 。 

e 机 可 学 习 或 者 图 计算 等 对 应 于 数据 复 用 十 分 频繁 和 重复 迭代 次 数 较 多 的 应 用 程序 。 

。 对 于 数据 保存 的 安全 化 级 别 也 特别 高 ， 例 如 流 计算 中 需要 实时 统计 过 去 某 段 时 间 的 数 

据 ， 需 要 数据 有 极 高 的 安全 化 等 级 。 

以 上 情况 都 可 以 通过 checkpoint 借用 HDFS 的 高 容错 特性 来 增强 数据 的 安全 性 ， 同 时 也 
减少 了 数据 重新 计算 时 的 开销 。 


Checkpoint 工作 机 制 解析 


1.。Checkpoint 的 创建 

Spark 关于 Checkpoint 的 源 代码 位 于 RDD. Scala 文件 中 的 Checkpoint 方法 ， 具 体内 容 如 
下 所 示 。 从 中 可 以 看 出 在 创建 Checkpoint 时 ，Spark 会 先 判断 是 否 有 CheckpointDir 的 地 址 
(存放 Checkpoint 数据 内 容 文件 的 地 址 ) ， 若 不 存在 则 报错 ; 若 存 在 再 检测 已 有 的 Checkpoint 


信息 ， 看 是 否 存 在 Checkpoint ， 如 果 没 有 ， 则 创建 CheckpointData， 其 中 包含 了 Checkpoint 的 
兰 自 


百 和 @\o 





1. def checkpoint( ) :Unit = RDDCheckpointData. synchronized | 

六 // NOTE :we use a global lock here due to complexities downstream with ensuring 

3 // children RDD partitions point to the correct parent partitions. In the future 

4 // we should revisit this consideration. 

Ss // 判 断 是 否定 义 了 checkpoint 文件 的 保存 地 址 

6 if (context. checkpointDir isEmpty ) | 

又 // 如 过 没有 定义 , 则 返回 异常 ,未 定义 checkpoint 文件 夹 

8 throw newSparkException( " Checkpoint directory has not been set in the SparkContext" ) 
9 | else if (checkpointData. isEmpty) | 


10. // 创 建 checkpointData, 其 中 包含 了 checkpoint 的 信息 

11. checkpointData = Some( new ReliableRDDCheckpointDatal this) ) 
12. | 

le 


在 Spark 中 ， 某 RDD 进行 Checkpoint 操作 后 会 将 此 RDD 的 依赖 关系 清空 ， 此 项 变化 在 
算法 计算 中 具有 极 大 的 意义 ,假设 一 个 运算 步骤 有 100 步 (同一 个 Stage 中 ) ，Spatk 框架 会 
在 计算 时 将 这 100 步 的 函数 合并 为 一 个 大 函数 ， 然 后 进行 计算 ， 而 如 果 在 第 90 步 处 进行 了 
Checkpoint， 则 Spark 计算 时 将 前 90 步 函 数 合 并 为 一 个 大 的 函数 串 进行 计算 ， 并 在 计算 完成 
时 进行 保存 ， 之 后 10 步 的 函数 合并 为 一 个 大 的 函数 串 进行 计算 。 如 果 出 现 错误 ， 只 需要 对 
后 10 步 进行 计算 , 具体 源 代码 如 下 所 示 : 第 10 行 中 便 是 RDD 进行 Checkpoint 时 会 调用 
rdd. markCheckpointed( ) 方 法 ， 而 此 方法 将 RDD 的 dependency 进行 了 清空 操作 。 
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1l. valnewRDD = doCheckpoint( ) 

之 

3 // Update our state and truncate the RDD lineage 

4 RDDCheckpointData. synchronized | O) 
也 /设置 保存 的 数据 

6 cpRDD = Some( newRDD) 

7 // 设 置 状态 

8 cpState = Checkpointed 

9. /清理 依赖 关系 

10. rdd. markCheckpointed( ) 

11. } 

jl 

13. private| spark | def markCheckpointed( ) :Unit = | 

14. clearDependencies( ) 

ss partitions_ = null 

16. deps = null // Forget the constructor argument for dependencies too 
ye 

18. 


19. protected def clearDependencies( ) | 
20. // 依 赖 关 系 清空 
2 dependencies_ = null 


2 


2. Checkpoint 的 写 入 

写 人 数据 至 Checkpoint 文件 的 源 代码 位 于 ReliableCheckpointRDD. Scala 的 writeRDDTo- 
CheckpointDirectory( ) 。 如 下 面 的 源 代码 所 示 ， 分 别 完成 对 于 checkpointDir 目录 下 的 文件 的 
创建 和 具体 内 容 的 写 入 。 
































1. def writeRDDToCheckpointDirectory[ T:ClassTag | ( 

2 originalRDD. RDD[ T], 

3 checkpointDir: String, 

4. blockSize:Int = —1):ReliableCheckpointRDD| T] = | 

3 

6. val sc = originalRDD. sparkContext 

gk 

8. // 根 据 checkpoint 的 设置 路 径 创 建文 件 夹 

2 val checkpointDirPath = new Path( checkpointDir) 

10. val fs = checkpointDirPath. getFileSystem( sc. hadoopConfiguration ) 
11. /判断 文件 夹 是 否 创 建成 功 

12 if (I!fs. mkdirs( checkpointDirPath ) ) | 

13. throw newSparkException( s" Failed to create checkpoint path $checkpointDirPath" ) 
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// 将 Hadoop 配置 文件 反 序列 化 后 以 广播 的 方式 创建 


























val broadcastedConf = sc. broadcast( 


new SerializableConfiguration( sc. hadoopConfiguration ) ) 











// 运 行 一 个 新 job ,将 需要 进行 checkpoint 的 文件 写 和 人 创建 的 checkpoint 文件 夹 中 


| 





sc. runJob( originalRDD ， 
writePartitionToCheckpointFile| T | (checkpointDirPath. toString ,broadcastedConf) _) 


if (originalRDD. partitioner nonEmpty ) | 
writePartitionerToCheckpointDir( sc ,originalRDD. partitioner. get, checkpointDirPath ) 


val newRDD = new ReliableCheckpointRDD[ T]( 

sc, checkpointDirPath. toString ,originalRDD. partitioner ) 
/判断 之 前 的 两 次 内 容 是 否 一 致 ,确保 写 和 的 文件 正确 无 误 
if (newRDD. partitions. length1= originalRDD. partitions. length ) | 





throw newSparkException( 
s" Checkpoint RDD $newRDD($ | newRDD. partitions. length| ) has different " + 
s" number of partitions from original RDD $originalRDD 
($ | originalRDD. partitions. length| )" ) 


| 
newRDD 


3. Checkpoint 的 触发 

当 需 要 对 已 进行 了 Checkpoint 的 数据 进行 处 理 时 ， 框架 默认 运行 docheckpoint 方法 〈 如 
下 所 示 )。 若 当前 RDD 的 checkpointData 是 被 定义 的 (此 RDD 已 被 进行 Checkpoint) ， 则 获 
得 数据 ; 若 当 前 RDD 的 checkpointData 是 未 被 定义 的 ， 则 按照 依赖 遍历 RDD 查询 此 RDD 依 
赖 RDD 是 否 存在 Checkpoint。 




















private|l spark | def doCheckpoint( ) :Unit = | 


RDDOperationScope. withScope( sc,"checkpoint" ,allowNesting = false,ignoreParent = true) | 
if ( ldoCheckpointCalled ) | 
doCheckpointCalled = true 
// 判 断 当 前 RDD 是 否 是 被 标记 的 checkpointRDD 
if (checkpointData. isDefined ) | 
// 直 接 获 取 checkpoint 数据 


checkpointData. get. checkpoint( ) 





| else | 
// 根 据 依赖 关系 向 前 回溯 查找 到 进行 checkpoint 的 RDD ,并 获取 checkpoint 数据 
dependencies. foreach( _. rdd. doCheckpoint( ) ) 
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Section | E 
RDD 容错 原理 及 其 四 大 核心 要 点 a 


攻 RDD 容错 原理 


由 于 RDD 不 同 的 依赖 关系 ， 导 致 Spark 对 于 不 同 的 依赖 关系 有 不 同 的 处 理 方式 。 

e 对 于 宽 依赖 而 言 ， 由 于 宽 依 赖 实质 是 指 父 RDD 的 一 个 分 区 会 对 应 一 个 子 RDD 的 多 个 
分 区 ， 在 此 情况 下 出 现 部 分 计算 结果 的 丢失 ， 单 一 计算 丢失 的 数据 无 法 达到 效果 ， 便 
重新 计算 该 步骤 所 有 的 数据 ， 从 而 会 导致 计算 数据 的 重复 。 

e 对 于 罕 依 赖 而 言 ， 由 于 窒 依 赖 实质 是 指 父 RDD 的 分 区 最 多 被 一 个 子 RDD 所 使 用 ,在 
此 情况 下 出 现 部 分 计算 的 错误 ， 与 之 计算 相关 只 是 出 错 部 分 所 依赖 的 父 RDD 相关 部 
分 的 数据 ， 不 需要 重新 计算 所 有 数据 ， 只 需要 重新 计算 出 错 部 分 的 数据 。 


RDD 容错 的 四 大 核心 要 点 


对 于 Spark 框架 层面 的 容错 机 制 ， 主 要 可 以 分 为 三 大 层面 ， 分 别 为 调度 层 (包含 DAG 
生成 和 Task 重 算 两 大 核心 ) 、RDD 血统 层 和 Checkpoint 层 。 其 中 包含 SparkRDD 容错 的 4 大 
核心 要 点 : 

e Stage 输出 失败 ， 上 层 调度 器 DAGScheduler 重 试 ; 

e Spark 计算 中 Task 内 部 任务 失败 ， 底 层 调 度 器 重 试 ; 

。 RDD Lineage 血统 中 罕 依 赖 、 宽 依赖 计算 ; 

e Checkpoint 缓存 。 

1. 调度 层 

从 调度 层面 讲 ， 错 误 主 要 出 现在 两 个 方面 ， 分 别 是 在 Stage 输出 时 出 错 和 计算 时 出 错 。 

(1) DAG 生成 层 

Stage 输出 失败 ， 上 层 调度 器 DAGScheduler 会 进行 重 试 ， 如 下 面 的 源 代码 所 示 。 

















/六 米 
* Resubmit any failed stages. Ordinarily called after a small amount of time has passed since 
* the last fetch failure. 
*/ 
private| scheduler | def resubmitFailedStages( ) | 
// 判 断 是 否 存 在 失败 的 Stages 
if (failedStages. size >0) | 


1 
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// Failed stages may be removed by job cancellation ,so failed might be empty even if 


// the ResubmitFailedStages event has been scheduled. 

// 输 出 日 志 

logInfo( " Resubmitting failed stages" ) 

clearCacheLocs( ) 

// 获 取 所 有 失败 Stage 的 列表 

val failedStagesCopy = failedStages. toArray 

// 清 空 failedStages 

failedStages. clear( ) 

// 对 之 前 获取 的 所 有 失败 的 Stage 根据 jobld 进行 排序 后 进行 逐一 的 重 试 
for( stage <— failedStagesCopy. sortBy( _. firstJobld ) ) | 





submitStage ( stage ) 


| 


submitWaitingStages( ) 
| 


(2) Task 计算 层 
Spark 计算 过 程 中 ， 计 算 内 部 某 个 Task 任务 出 现 失败 ， 底 层 调 度 器 会 对 此 Task 进行 知 
干 次 的 重 试 (默认 为 4 次， 如 下 述 代 码 第 2 行 所 示 )。 以 下 为 相关 信息 的 源 代码 。 





oD ed rm eh 





privatel spark | classTaskSchedulerImpl( ) | 
def this( sc:SparkContext) = this( se, sc. conf getInt( " spark. task. maxFailures" ,4) ) 


// 下 列 代 码 来 源 TaskSetManager. scala 
def handleFailedTask ( tid : Long , state : TaskState ,reason: TaskEndReason ) | 
// 对 于 失败 的 Task 的 numFailures 进行 计数 加 1 
numFailures( index) +=1 
// 判 断 失 败 的 Task 次 数 是 否 大 于 设 定 的 最 大 失败 次 数 ,如 果 大 于 则 输出 日 志 , 并 不 
再 重 试 


if (numFailures(index) >=maxTaskFailures ) | 








logError( "Task % din stage %s failed % d times;aborting job". format( 

index ,taskSet. id ,maxTaskFailures ) ) 

abort("Task %d in stage %s failed % d times ,most recent failure:% s\nDriver stack- 
trace:" 

. format( index , taskSet. id, maxTaskFailures ,failureReason ) ,failureException ) 


return 


| 
// 如 果 运 行 的 Task 为 0, 则 完成 Task 步骤 
maybeFinishTaskSet( ) 
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2. RDD Lineage 血统 层 容 错 
Spark 中 RDD 采用 高 度 受 限 的 分 布 式 共享 内 存 ， 且 新 的 RDD 的 产生 只 能 够 通过 其 他 
RDD 上 的 批量 操作 来 创建 ， 依 赖 于 以 RDD 的 Lineage 为 核心 的 容错 处 理 ， 在 迭代 计算 方面 
比 Hadoop 快 20 多 倍 ， 同 时 还 可 以 在 5 ~7s 内 交互 式 的 查询 TB 级 别 的 数据 集 。 
Spark RDD 实现 基于 Lineage 的 容错 机 制 ， 基 于 RDD 的 各 项 Transformation 构成 了 com- 
pute chain， 在 部 分 计算 结果 丢失 的 时 候 可 以 根据 Lineage 重新 计算 恢复 。 
。 在 罕 依 赖 中 ， 在 子 RDD 的 分 区 丢失 要 重 算 父 RDD 分 区 时 ， 父 RDD 相应 分 区 的 所 有 
数据 都 是 子 RDD 分 区 的 数据 ， 并 不 存在 元 余 计 算 ; 
。 在 宽 依 赖 情况 下 ， 丢 失 一 个 子 RDD 分 区 重 算 的 每 个 父 RDD 的 每 个 分 区 的 所 有 数据 并 
不 是 都 给 丢失 的 子 RDD 分 区 用 的 ， 会 有 一 部 分 数据 相当 于 对 应 的 是 未 丢失 的 子 RDD 
分 区 中 需要 的 数据 ， 这 样 就 会 产生 宛 余 计算 开销 和 巨大 的 性 能 浪费 。 
3. Checkpoint 层 容 错 
Spark Checkpoint 通过 将 RDD 写 入 Disk 做 检查 点 ， 是 Spark lineage 容错 的 辅助 ，lineage 
过 长 会 造成 容错 成 本 过 高 ， 这 时 候 在 中 间 阶 段 做 检查 点 容错 ， 如 果 之 后 有 结 点 出 现 问题 而 丢 
失 分 区 ， 从 做 检查 点 的 RDD 开始 重 做 Lineage ， 就 会 减少 开销 。 
Checkpoint 主要 适用 于 以 下 两 种 情况 : 
e DAG 中 的 Lineage 过 长 ， 如 果 重 算 时 会 开销 太 大 ,例如 在 PageRank 、ALS 等 ; 
e 尤其 适合 于 在 宽 依 赖 上 做 Checkpoint， 这 个 时 候 就 可 以 避免 应 为 Lineage 重新 计算 而 带 
来 的 元 余 计算 。 














2 通过 WordCount 实践 RDD 内 部 机 制 














2 ”WordCount 案例 实践 ， 





本 节 通 过 IDEA 逐步 调试 一 个 带 有 排序 功能 的 WordCount 案例 ， 让 读者 了 解 各 步 又 中 
RDD 的 具体 类 型 。 
1. WordCount 代码 





1. object WordCount | 

2 def main( args: Array| String | ) | 

3 val conf = new SparkConf( )//create SparkConf 

4 conf setAppName(" Wow,My First Spark App" )// 设 置 应 用 程序 名 
Se conf setMaster( "local" )// 设 置 为 本 地 运行 
6 

以 

8 

9 























val sc = new SparkContext( conf) 
val lines = sc. textFile("C://Users//feng//IdeaProjects// WordCount//src//SparkText. txt" ) 
val words = lines. flatMap | lines => lines. split(" " )| 


val pairs = words. map( word => (word,1) ) 





© 
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10. val reduce = pairs. reduceByKey( _+_) 

11. val sort_] = reduce. map( pair => (pair. _2,pair. _1)) 

2 val sort_ 2 = sort_1. sortByKey( false) 

[3 val sort_3 = sort 2. map( pair => (pair. .2 ,pair. _1)) 

14. val filter = sort_3. filter( pair => pair. 2 >2) 

lS filter. collect. foreach( wordNumberPair => println( wordNumberPair. _1 +" :" +wordNumber- 
Ba 

16. sc. stop( ) 

Pe 

18. | 


呈 序 使 用 的 SparkText. txt 文件 内 容 


hadoop hadoop hadoop 
spark Flink spark 
scala scala object 
object spark scala 
spark spark 

Hadoop hadoop 


3. 程序 WordCount 调试 结果 

通过 IDEA 的 逐步 调试 ， 会 在 调试 窗口 显示 每 一 行 代码 具体 操作 什么 类 型 的 RDD， 以 及 
此 RDD 通过 什么 依赖 关系 依赖 于 父 RDD 等 重要 信息 ( 见 图 2-16)， 程序 运行 结果 如 
图 2-17 所 示 。 








三 lines = {MapPartitionsRDD@5792} "MapPartitionsRDD[1] at textFile at WordCount.scala:14" 
宇 words = {MapPartitionsRDD@5806} "MapPartitionsRDD[2] at flatMap at WordCount.scala:151 
pairs = {MapPartitionsRDD@5811} "MapPartitionsRDD[3] at map at WordCount.scala:16" 
reduce = {ShuffledRDD@5961} "shuffledRDDI4] at reduceByKey at WordCount.scala:17" 
sort 1 = {MapPartitionsRDD@5968} "MapPartitionsRDD[5] at map at WordCount.scala:18" 
sort 2 = {ShuffledRDD@5983} "ShuffledRDDI[6] at sortBykey at WordCount.scala:19" 
sort 3 = {MapPartitionsRDD@5992} "MapPartitionsRDDI[7] at map at WordCount.scala:20" 
三 filter = {MapPartitionsRDD@6005} "MapPartitionsRDDI[8] at filter at WordCount.scala:21" 














I 








2-16 调试 过 程 图 





spark : 5 


hadoop : 5 


scala : 











图 2-17 WordCount 结果 
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EE 解析 RDD 生成 的 内 部 机 制 


本 节 基 于 上 小 节 程序 的 调试 结果 ， 逐 条 分 析 调试 语句 。 Cc) 
1. line = sc. textFile( ) 
本 语句 的 作用 在 于 从 外 部 数据 中 读 取 数据 ， 并 生成 MapPartitionsRDD。 此 处 需要 注意 : “SS 
如 图 2-18 所 示 ， 可 以 看 出 该 MapPartitionsRDD 的 依赖 为 HadoopRDD， 从 这 里 可 以 发 现 其 实 
textFile( ) 过 程 包含 两 个 步 又， 第 一 步 将 文件 内 容 转化 为 HadoopRDD (key - value 形式 ，key 
为 行 号 ) ， 第 二 步 将 HadoopRDD 转化 为 MapPartitionsRDD (value 形式 ,将 key - value 类 型 的 
key 删 去 ) 。 





三 lines = {MapPartitionsRDD@5790} "MapPartitionsRDDI[1] at textFile at WordCount.scala:14" 
留 f= {RDD$$anonfun$map$1 ye @6012} "<function3>" 
DD evidence$2 = {ClassTag$ $anon$1@6013} "scala.Tuple2" 
ke partitioner = {None$ @6014} "None" 
f 
f 


多 
1 


_SC = poe 
deps = = {$colon$colon@6015} "::" size = 1 





宇 0 = {Or neToOneDependeny@73 57} 

















2. words = line. flatMap() 

此 命令 对 于 RDD 采取 transformation (转换 ) 操作 ， 作 用 在 于 将 MapPartitionsRDD 中 的 
每 一 个 记录 进行 以 空格 为 标记 的 切 分 ， 并 把 每 一 个 RDD 的 切 分 结果 放 在 一 个 MapParti- 
tionRDD 中 。 

3. pairs = words. map ( word => ( word ,1) ) 

此 命令 对 于 RDD 采取 Transformation (转换 ) 操作 作用 在 于 将 MapPartitionsRDD 中 的 
每 一 个 记录 (如 Spark (value 类 型 )) 转换 为 key - value 类 型 (如 (spark,1) ) ， 便 于 下 一 步 
reduceByKey 操作 。 

4. reduce = pairs. reduceByKey(_+_) 

此 命令 对 于 RDD 采取 Action (动作 ) 操作 ， 作 用 在 于 通过 Shuffle 将 pairs 中 所 有 的 记录 
按照 key 相同 value 相 加 的 规则 进行 处 理 ， 并 把 结果 放 到 一 个 shuffleRDD 中 。 例 如 ， 
((spark,1),(spark,1) ) 变 成 ((spark,2) ) 。 

同时 需要 注意 以 下 两 点 : 首先 本 步骤 实质 上 分 为 两 个 步 又， 第 一 步 为 Local 级 别 的 Re- 
duce， 对 当前 计算 机 所 拥有 的 数据 先进 行 Reduce 操作 ， 生 成 MapPartitionsRDD; 第 二 步 为 
Shuffle 级 别 的 Reduce， 基 于 第 一 步 的 结果 ， 对 结果 进行 Shuffle - Reduce 操作 ， 生 成 最 终 的 
shuffleRDD 。 其 次 进行 Action 操作 时 ， 执 行 此 操作 之 前 的 所 有 转换 操作 ， 所 以 调试 过 程 中 会 
出 现 此 前 的 除 textFile 操作 外 的 执行 时 间 均 非常 短 ， 说 明 RDD 转换 操作 不 直接 进行 运算 。 

S. Sort_1 = reduce. map ( pair => (pair. 2,pair. _1)) 

此 命令 对 于 RDD 采取 Transformation (转换 ) 操作 ， 作 用 在 于 将 shuffleRDD 中 的 每 一 
记录 的 key 和 value 互 换 ， 生 成 一 个 新 的 MapPartitionsRDD。 例 如 ，(spark,2) 变 为 (2， a 
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6. sort 2 = SOrt_1. sortByKey (false) 

此 命令 对 于 RDD 采取 Action (动作 ) 操作 ， 作 用 在 于 将 MapPartitionsRDD 根据 key 进行 
排序 ， 并 生成 shuffleRDD。 

7. sort 3 = Sort 2. map (pair => (pair. 2 ,pair. 1)) 

此 命令 对 于 RDD 采取 Transfommation (转换 ) 操作 ， 作 用 在 于 将 shuffleRDD 中 的 每 一 个 记 
录 的 key 和 value 互 换 ， 生 成 一 个 新 的 MapPartitionsRDD。 例 如 ，(2,spark) 变 为 (spark ,2)。 

8. filter = sort_3. filter( pair => pair. 2 >2) 

此 命令 对 于 RDD 采取 Transformation (转换 ) 操作 ， 作 用 在 于 根据 value 值 第 选 MapPar- 
titionsRDD 中 的 数据 ， 输 出 value 大 于 2 的 记录 。 

9. 打印 输出 

最 后 通过 collect( ) 方 法 将 结果 收集 后 ， 使 用 foreach( ) 方 法 遍历 数据 并 通过 println( ) 方 
法 打印 出 所 有 数据 。 


用 漂 站 小 结 


本 章 主要 讲解 了 以 下 内 容 : RDD 之 间 的 宽窄 依赖 关系 的 形成 原因 ， 依 赖 关 系 的 作用 ， 
以 及 其 对 于 整体 框架 的 容错 的 效果 ; 并 对 基于 RDD 依赖 关系 产生 DAG 图 的 机 制 进行 了 基本 
讲解 ; 之 后 通过 对 TaskSchedulerImpl 的 解析 ， 详 细 解 释 了 RDD 如 何 进 入 运算 ， 如何 得 出 结 
果 ， 以 及 在 运算 过 程 中 进行 持久 化 的 原理 和 方式 。 

通过 本 章 内 容 的 学 习 ， 可 以 了 解 SparkRDD 的 本 质 和 Spark 计算 框架 的 内 容 。 
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医 吉明 部 署 模式 概述 


在 Spark 官网 部 署 页 面 (http: //spark. apache. org/ docs/latest/cluster - overview. html ) 
中 ， 可 以 看 到 当前 集群 支持 以 下 3 种 集群 管理 器 (Cluster Manager) 。 

1) Standalone: Spark 原生 的 简单 集群 管理 器 ， 使 用 Standalone 可 以 很 方便 地 搭建 一 个 
集群 。 

2) Apache Mesos: 一 个 通用 的 集群 管理 器 ， 可 以 在 上 面 运行 Hadoop MapReduce 和 一 些 
服务 型 的 应 用 。 

3) Hadoop YARN: 在 Hadoop 2 中 提供 的 资源 管理 器 。 

另外 ，Spark 提供 的 EC2 启动 脚本 ， 可 以 很 方便 地 在 Amazon EC2 上 启动 一 个 Standalone 
集群 。 

实际 上 ， 除 了 上 面 这 些 通用 的 集群 管理 器 外 ，Spark 内 部 也 提供 了 一 些 方便 用 户 测试 和 
学 习 的 简单 集群 部 署 模 式 。 为 了 更 全 面 地 理解 这 些 内 容 ， 本 节 会 从 Spark 应 用 程序 部 署 点 切 
入 ， 也 就 是 从 提交 一 个 Spark 应 用 程序 开始 ， 引 出 并 详细 解析 各 种 部 署 模式 。 











[ED 说 明 : 下 面 涉及 类 的 描述 时 ， 如 果 可 以 通过 类 名 唯一 确定 一 个 类 的 话 ， 将 直接 给 出 类 名 ; 如 果 不 能 ， 会 
先 给 出 全 路 径 的 类 名 ， 然 后 在 不 出 现 歧义 的 地 方 再 简写 为 类 名 。 
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< 应 用 程序 部 署 的 脚本 解析 


为 了 简化 应 用 程序 提交 的 复杂 性 ，Spark 提供 了 各 种 应 用 程序 提交 的 统一 入 口 ， 即 spark 
-submit 脚本 ， 应 用 程序 的 提交 都 间接 或 直接 地 调用 了 该 脚本 。 下 面 简单 分 析 几 个 脚本 ， 包 
含 : . /bin/pyspark、. /bin/sparkR、 ./bin/spark - shell 、. /bin/spark - sql 、. /bin/run - exam- 
ple， 以 及 所 有 脚本 最 终 都 调用 到 的 一 个 执行 Java 类 的 脚本 . /bin/spark - class。 

1. 脚本 spark - shell 

通过 该 脚本 可 以 打开 使 用 Scala 语言 进行 开发 和 调试 的 交互 式 界面 ， 脚 本 代码 如 下 。 
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1. 

2. function main( ) | 

2 

4. "$|{SPARK_HOME}"/bin/spark - submit —— class org. apache. spark. repl. Main 一 一 name " 
Spark shell” "$@" 

5. stty icanon echo >/dev/null 2 > &1 

6. else 

7. export SPARK_SUBMIT_OPTS 

8. "$ {SPARK_HOME}"/bin/spark - submit —— class org. apache. spark. repl. Main —— name " 
Spark shell” "$@" 

De 

10. | 

11. 





对 应 第 4 行 和 第 8 行 代码 ， 调 用 了 应 用 程序 提交 脚本 spark - submit。 脚 本 spark - shell 
的 基本 用 法 如 下 。 


"Usage:. /bin/spark - shell [ options ]" 


其 他 的 脚本 类 似 ， 下 面 分 别针 对 各 个 脚本 的 用 法 (具体 用 法 可 查看 脚本 的 帮助 信息 ， 
比如 通过 -- help 选项 来 获取 ) 与 关键 执行 语句 等 进行 简单 解析 。 








[9 说 明 : 要 了 解 如 何 使 用 工具 (如 脚本 )， 最 根本 的 是 先 查 看 其 帮助 信息 ， 然 后 在 此 基础 上 进行 
扩展 。 





2. 脚本 . /bin/pyspark 
通过 该 脚本 可 以 打开 使 用 Python 语言 开发 和 调试 的 交互 式 界面 。 
1) 该 脚本 的 用 法 如 下 。 


"Usage:. /bin/pyspark [ options ]" 
2) 该 脚本 的 执行 语句 如 下 。 


exec "$|SPARK_HOME}"/bin/ spark - submit pyspark — shell - main —— name "PySparkShell" "$ 
@ 中 


3. 脚本 . /bin/sparkR 
通过 该 脚本 可 以 打开 使 用 SparkR 语言 开发 和 调试 的 交互 式 界面 。 
1) 该 脚本 的 用 法 如 下 。 


"Usage:. /bin/sparkR [options]" 


2) 该 脚本 的 执行 语句 如 下 。 
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exec "$|SPARK_ HOME}"/bin/spark - submit sparkr - shell - main "$@" 


4. 脚本 . /bin/spark -sql 
通过 该 脚本 可 以 打开 使 用 Spark Sql 语言 开发 和 调试 的 交互 式 界面 。 ©) 
1) 该 脚本 的 用 法 如 下 。 





"Usage:. /bin/spark — sql [ options | [ cli option]" 
2) 该 脚本 的 执行 语句 如 下 。 


exec "$|SPARK_ HOME}"/bin/spark - submit —— class org. apache. spark. sql. hive. thriftserver. 
SparkSQLCLIDriver "$@" 


5. 脚本 . /bin/run - example 
可 以 通过 该 脚本 运行 Spark 自 带 的 案例 代码 ， 该 脚本 中 会 自动 补 全 案例 类 的 路 径 。 
1) 该 脚本 的 用 法 如 下 。 


1. echo "Usage:. /bin/run - example < example - class > [ example - args]" 1 > &2 

2. echo " - set MASTER =XX to use a specific master" 1 > &2 

3. echo " — can use abbreviated example class name relative to com. apache. spark. examples" 1 > &2 
4. echo" (e.g. SparkPi,mllib. LinearRegression,streaming. KinesisWordCountASL)" 1 > &2 


2) 该 脚本 的 执行 语句 如 下 。 


exec "$|SPARK_HOME}"/bin/spark - submit \ 
—— master $EXAMPLE_MASTER \ 
——class$EXAMPLE_ CLASS \ 
"$SPARK_EXAMPLES_JAR" \ 
"$@" 


SU nr 


6. 脚本 . /bin/spark - submit 

. /bin/spark - submit 是 提交 Spark 应 用 程序 最 和 常用 的 一 个 脚本 。 从 前 面 各 个 脚本 的 解析 
可 以 看 出 ， 各 个 脚本 最 终 都 调用 了 . /bin/spark - submit 脚本 。 

1) 用 法 。 该 脚本 的 用 法 需要 从 源 代码 中 获取 ， 具 体 源 代码 位 置 参 考 SparkSubmitArgu- 
ments 类 的 方法 printUsageAndExit， 代 码 如 下 。 


l. val command = sys. env. get("_SPARK CMD_USAGE" ). getOrElse( 

2 """Usage:spark - submit [ options | < app jar | python file > [ app arguments | 

2 | Usage:spark - submit —— kill [submission ID] ~— master [ spark://...] 

4 | Usage: spark — submit —— status [ submission ID ] - — master | spark://...]""" 


. stripMargin ) 


2) 该 脚本 的 执行 语句 如 下 。 









1. 
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exec "$|SPARK_HOME}"/bin/spark - class org. apache. spark. deploy. SparkSubmit "$@" 


7. 脚本 . /bin/spark - class 
该 脚本 是 所 有 其 他 脚本 最 终 都 调用 到 的 一 个 执行 Java 类 的 脚本 。 其 中 关键 的 执行 语句 


如 下 。 


-2 


MN 
1 
丑 





CMD=() 
while IFS =read -d -r ARG;do 
CMD +=( "$ARG") 
done << ( "$RUNNER" -cp "$LAUNCH_CLASSPATH" org. apache. spark. launcher. Main "$ 
@") 
exec "$|CMD[@ ]}" 


负责 运行 的 RUNNER 变量 设置 如 下 。 


# Find the java binary 

// 将 RUNNER 设置 为 java 

i [—-n"$|JAVA HOME}" |];then 
RUNNER = "$|JAVA_HOME}/bin/java" 


else 























if | command —v java | ;then 
RUNNER = " java" 
else 
echo "JAVA HOME is not set" > &2 
exit 1 
fi 


在 脚本 中 ，LAUNCH_CLASSPATH 变量 对 应 了 Java 命令 运行 时 所 需 的 classpath 信息 。 
而 最 终 Java 命令 启动 的 类 是 org. apache. spark. launcher. Main，Main 类 的 入 口 函数 main 会 
根据 输入 参数 构建 出 最 终 执行 的 命令 ， 即 这 里 返回 的 $1 CMD[ @ ] | 信息， 然后 通过 exec 
执行 。 
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本 节 从 应 用 部 署 的 角度 解析 相关 的 源 代码 ， 主 要 包括 脚本 提交 时 对 应 JVM 进程 启动 的 
主 类 org. apache. spark. launcher. Main 、 定义 应 用 程序 提交 的 行为 类 型 的 类 org. apache. spark. 
deploy. SparkSubmitAction 、 应 用 程序 封装 底层 集群 管理 器 和 部 署 模 式 的 类 org. apache. spark. 
deploy. SparkSubmit， 以 及 代表 一 个 应 用 程序 的 驱动 程序 的 类 org, apache. spark. SparkContext。 
1.Main 解析 


从 前 面 的 脚本 分 析 可 以 得 出 ， 最 终 都 是 通过 org. apache. spark. launcher Main 类 (下 面 简 
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称 Main 类 ) 来 启动 应 用 程序 的 ， 因 此 ， 首 先 来 分 析 Main 类 。 
在 Main 类 的 源 代码 中 ， 类 的 注释 如 下 。 


i @ 


* Spark 启动 器 的 命令 行 接口 。 在 Spark 脚本 内 部 使 用 


* Command line interface for the Spark launcher. Used internally by Spark scripts. 
*/ 




















oe 


对 应 在 Main 对 象 的 入 口 方法 main 上 的 注释 如 下 。 

















1l. /六 米 

2 * Usage:Main [class| [class args| 

3 * <p> 

4. * 命令 行 界面 工作 在 两 种 模式 下 

5. * This CLI works in two different modes : 

6. * <ul> 

7 * <li>"spark—submit" .if <i>class </i>is "org. apache. spark. deploy. SparkSubmit" ,the 
8. 水 | @ link SparkLauncher| class is used to launch a Spark application. </li> 

9. * <li>"spark—class" :if another class is provided,an internal Spark class is run. </li> 
10. * </u > 

11. 

12. public static void main( String[ | argsArray ) throws Exception | 

13. 


Main 类 主要 有 两 种 工作 模式 ， 分 别 描述 如 下 。 
(1) spark - submit 
启动 器 要 启动 的 类 为 " org. apache. spark. deploy. SparkSubmit" 时 ， 对 应 为 " spark - sub- 

mit" 工作 模式 。 此 时 ， 使 用 SparkSubmitCommandBuilder 类 来 构建 启动 命令 。 

(2) spark - class 

启动 咒 要 启动 的 类 是 除 SparkSubmit 之 外 的 其 他 类 时 ， 对 应 为 "spark - class" 工作 模式 。 
此 时 ,使 用 SparkClassCommandBuilder 类 的 buildCommand 方法 来 构建 启动 命令 。 

以 "spark - submit" 工作 模式 为 例 ， 对 应 的 在 构建 启动 命令 的 SparkSubmitCommandBuilder 
类 中 ， 上 述 调用 的 SparkClassCommandBuilder 构造 函数 定义 如 下 。 








1. SparkSubmitCommandBuilder( List < String > args ) | 

之 this. sparkArgs = new ArrayList < String > ( ) ; 

3 List < String > submitArgs = args; 

4. // 根据 输入 的 第 一 个 参数 设置 ,包括 主 资源 appResource 等 
3 

0 

7 





if (args. size( ) >0 && args. get(0). equals(PYSPARK_SHELL) ) | 
this. allowsMixedArguments = true; 


appResource = PYSPARK_ SHELL_RESOURCE:; 
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8. submitArgs = args. subList(1,args. size( ) ) ; 

9. | else if (args. size( ) >0 && args. get(0). edquals(SPARKR_SHELL) ) | 
10. this. allowsMixedArguments = true; 

11. appResource = SPARKR_SHELL_RESOURCE; 

[2 submitArgs = args. subList( 1 ,args. size( ) ) ; 

i | else | 

14. this. allowsMixedArguments = false; 

15 | 

16. 

17. | 


从 这 里 初步 的 参数 解析 可 以 看 出 ， 前 面 脚本 中 的 参数 与 最 终 对 应 的 主 资源 间 的 对 应 关系 
如 表 3-1 所 示 。 





表 3-1 脚本 中 的 参数 与 主 资源 间 的 对 应 关系 














脚 本 名 脚本 中 的 参数 主 资 源 
. /bin/ pyspark PYSPARK_SHELL = " pyspark - shell ~ main" PYSPARK_SHELL_RESOURCE = " pyspark - shell" 
. /bin/ sparkR SPARKR_SHELL = " sparkr - shell - main" SPARKR_SHELL_RESOURCE = " sparkr - shell" 























如 果 继 续 跟 踪 appResource 赋值 的 源 代码 ， 可 以 跟踪 到 一 些 特殊 类 的 类 名 与 最 终 对 应 的 
主 资源 间 的 对 应 关系 ， 部 分 如 表 3-2 所 示 。 


表 3-2 特殊 类 的 类 名 与 主 资源 间 的 对 应 关系 














参考 的 脚本 名 类 名 主 资源 
. /bin/ spark - shell " org. apache. spark. repl. Main" "spark — shell" 
. /bin/spark — sql "org. apache. spark. sql. hive. thriftserver. SparkkSQLCLIDriver" "spark — internal" 
. /sbin/ start - thriftserver " org. apache. spark. sql. hive. thriftserver. HiveThriftServer2" "spark — internal" 








有 兴趣 的 话 可 以 继续 跟踪 SparkClassCommandBuilder 类 的 buildCommand 方法 的 源 代码 ， 
查看 构建 的 命令 具体 有 哪些 

通过 Main 类 的 简单 解析 可 以 将 前 面 的 脚本 分 析 结 果 与 后 面 即将 进行 分 析 的 SparkSub- 
mit 类 关联 起 来 ， 以 便 进一步 解析 与 应 用 程序 提交 相关 的 其 他 源 代码 。 

从 前 面 的 脚本 分 析 可 以 看 到 ， 在 提交 应 用 程序 时 ，Main 所 启动 的 类 ， 也 就 是 用 户 最 终 
提交 执行 的 类 是 org. apache. spark. deploy. SparkSubmit。 因 此 下 面 开始 解析 SparkSubmit 相关 
的 源 代码 ， 包 括 提交 行为 的 定义 、 提 交 时 的 参数 解析 ， 以 及 最 终 提交 运行 的 代码 解析 。 

2. SparkSubmitAction 解析 

SparkSubmitAction 定义 了 提交 应 用 程序 的 行为 类 型 ， 源 代码 如 下 。 



































privatel[ deploy | object SparkSubmitAction extends Enumeration | 
type SparkSubmitAction = Value 
val SUBMIT, KILL, REQUEST_STATUS = Value 

| 


2 
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从 源 代码 中 可 以 看 到 ， 分 别 定义 了 SUBMIT 、KILL 和 REQUEST_STATUS 这 3 种 行为 类 
型 ， 对 应 提交 应 用 、 停 止 应 用 和 查询 应 用 的 状态 

3. SparkSubmit 解析 

SparkSubmit 的 全 路 径 为 org. apache. spark. deploy. 0 从 SparkSubmit 类 的 注释 
可 以 看 出 ，SparkSubmit 是 启动 一 个 Spark 应 用 程序 的 主 入 口 点 ， 这 与 前 面 从 脚本 分 析 得 到 的 
结论 是 一 致 的 。 首 先 来 看 SparkSubmit 类 的 注释 ， 如 下 所 示 。 








Wk 
* 启动 一 个 Spark 应 用 程序 的 主 入 口 点 


* Main gateway of launching a Spark application. 





* 
* This program handles setting up the classpath with relevant Spark 
* dependencies and provides 


* a layer over the different cluster managers and deploy modes that Spark supports. 
*/ 


90 


SparkSubmit 会 帮助 用 户 设 置 Spark 相关 依赖 包 的 classpath 设置 ， 同 时 ,为 了 帮助 用 户 简 
化 提交 应 用 程序 的 复杂 性 ， pk le 提供 了 一 个 抽象 屋 ， 封 装 了 底层 复杂 的 集群 管理 器 
与 部 署 模式 的 各 种 差异 点 。 即 ， 通 过 SparkSubmit 的 封装 ， 集 群 管理 兢 与 部 署 模式 对 用 户 而 
言 是 透明 的 。 

SparkSubmit 透明 化 (通过 SparkSubmit 的 封装 ， 集 群 管理 需 与 部 署 模式 对 用 户 而 言 是 透 
明 的 ) 的 集群 管理 器 定义 的 源 代码 如 下 。 























// 集群 管理 吉 

// Cluster managers 

private val YARN =1 

Private val STANDALONE =2 

private val MESOS =4 

private val LOCAL =8 

private val ALL_CLUSTER_MGRS = YARN | STANDALONE | MESOS | LOCAL 


A 


被 SparkSubmit 透明 化 的 部 署 模 式 定义 的 源 代码 如 下 。 


// 部 署 模式 

//Deploy modes 

private val CLIENT = 1 

private val CLUSTER =2 

private val ALL_DEPLOY_MODES = CLIENT | CLUSTER 


A 


作为 提交 应 用 程序 的 入 口 点 ，SparkSubmit 中 根据 具体 的 集群 管理 器 进行 参数 转换 、 参 
数 校 验 等 操作 ， 比如 对 模式 的 检查 ， 代码 中 给 出 了 针对 特定 情况 下 不 文 持 的 集群 管理 器 与 部 
署 模式 ， 在 这 些 模式 下 提交 应 用 程序 会 直接 报错 退出 。 
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1. /不 支持 的 集群 管理 需 与 部 署 模式 

2. / 使 用 了 模式 匹配 与 守卫 语句 

3. // The following modes are not supported or applicable 

4. (clusterManager,deployMode) match | 

Ss case( MESOS,CLUSTER )if args. isR => 

6. printErrorAndExit(" Cluster deploy mode is currently not supported for R" + 

和 "applications on Mesos clusters. " ) 

8. case(STANDALONE ,CLUSTER ) if args. isPython => 

9. printErrorAndExit( " Cluster deploy mode is currently not supported for python " + 
10. "applications on standalone clusters. " ) 

11. case(STANDALONE,CLUSTER)if args. isR => 

12. printErrorAndExit( " Cluster deploy mode is currently not supported for R"+ 

13. "applications on standalone clusters. " ) 

14. case( _,CLUSTER )if isShell( args. primaryResource) => 

15. printErrorAndExit( "Cluster deploy mode is not applicable to Spark shells. " ) 

16. case( _,CLUSTER )if isSqlShell( args. mainClass) => 

I printErrorAndExit( " Cluster deploy mode is not applicable to Spark SQL shell. " ) 
18. case( _,CLUSTER )if isThriftServer( args. mainClass) => 

19. printErrorAndExit( "Cluster deploy mode is not applicable to Spark Thrift server. " ) 
20. case _=> 

2100 


首先 ， 一 个 程序 运行 的 入 口 点 对 应 单 例 对 象 的 main 函数 ， 因 此 在 执行 SparkSubmit 时 ， 
对 应 的 入 口 点 是 objectSparkSubmit 的 main 函数 ， 具 体 代 码 如 下 。 





1 // 入 口 点 函数 main 的 定义 

2. def main(args: Array[ String] ) :Unit = | 

3 val appArgs = new SparkSubmitArguments( args ) 

Zi 

5. ”// 根据 3 种 行为 分 别 进行 处 理 

6. appArgs. action match | 

办 case SparkSubmitAction. SUBMIT => submit( appArgs) 
8. case SparkSubmitAction. KILL => kill( appArgs) 

9 case SparkSubmitAction. REQUEST STATUS => requestStatus( appArgs ) 
10. | 

11. | 


其 中 ,第 3 行 代码 中 的 SparkSubmitArguments 类 对 应 用 户 调 用 提交 脚本 spark - submit 时 
传人 的 参数 信息 。 对 应 的 脚本 的 帮助 信息 (. /bin/spark - submit -- help) 也 是 由 该 类 的 
printUsageAndExit 方法 提供 的 。 

找到 上 面 的 入 口 点 代码 之 后 ， 就 可 以 开始 分 析 其 内 部 的 源 代码 。 对 应 参数 信息 的 Spark- 
SubmitArguments 可 以 参考 脚本 的 帮助 信息 来 查看 具体 参数 所 对 应 的 含义 。 参 数 分 析 之 后 ， 
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便 是 各 种 提交 行为 的 具体 处 理 。SparkSubmit 支持 SparkSubmitAction 包含 的 3 种 行为 ,下 面 
以 行为 SparkSubmitAction. SUBMIT 为 例 进行 分 析 ， 其 他 行为 也 可 以 从 各 自 的 具体 处 理 代码 进 
行 分 析 。 
对 应 处 理 SparkSubmitAction. SUBMIT 行为 的 代码 入 口 点 为 submit( appArgs)， 进 入 该 方 > 
法 ， 即 进入 提交 应 用 程序 的 处 理 方法 的 具体 代码 如 下 。 






































1. // SparkSubmitAction. SUBMIT 行为 类 型 的 具体 处 理 方法 

2. private def submit(args:SparkSubmitArguments) :Unit = | 

3. /7 准备 应 用 程序 提交 的 环境 ,该 步 又 包含 了 内 部 封装 的 各 个 细节 处 理 

4. val( childArgs ,childClasspath ,sysProps , childMainClass ) = prepareSubmitEnvironment( args ) 
5 

6. def doRunMain( ) :Unit = | 

gi if (args. proxyUser!= null) | 

8. val proxyUser = UserGroupInformation. createProxyUser( args. proxyUser， 

9. UserGroupInformation. getCurrentUser( ) ) 

10. try | 

11. proxyUser. doAs( new PrivilegedExceptionAction[ Unit |] ( ) | 

| 多 override def run( ) :Unit = | 

13. runMain( childArgs, childClasspath ,sysProps ,childMainClass ,args. verbose ) 
14. } 

15. 1!) 

16. | catch | 

I 

18. } 

19. | else | 

20. runMain( childArgs, childClasspath , sysProps ,childMainClass ,args. verbose ) 
2 | 

2 } 

2 

24. // Standalone 集群 模式 下 ,有 两 种 提交 应 用 程序 的 方式 

2 


26. //1、 传统 的 Akka 网 关 方 式 使 用 o. a. s. deploy. Client 进行 封装 
27. //2、Spark 1.3 使 用 了 REST - based 网 关 方式 ,作为 Spark 1.3 的 缺 省 方法 ,如 果 master 结 点 
不 是 REST 服务 器 结 点 ,spark 应 用 程序 提交 时 会 切换 到 传统 的 网 关 模 式 

















28. if (args. isStandaloneCluster && args. useRest) | 

2 try | 

30. // scalastyle :off println 

31. printStream. println ( " Running Spark using the REST application submission 
protocol. " ) 

32. // scalastyle :on println 

33. doRunMain( ) 

34. | catch | 
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35. // 失败 的 话 则 使 用 传统 的 提交 方式 

36. 

Sy case e:SubmitRestConnectionException => 

38. printWarning( s" Master endpoint$ | args. master| was not a REST server "+ 
39. " Falling back to legacy submission gateway instead. " ) 





40. ”// 重新 设置 提交 方式 的 控制 开关 


41. args. useRest =false 























42. submit( args ) 

43. } 

44. // In all other modes, just run the main class as prepared 
45. | else | 

46. doRunMain( ) 

47. } 

48. } 


其 中 ， 最 终 运 行 所 需 的 参数 都 由 prepareSubmitEnvironment 方法 负责 解析 和 转换 ， 然 后 
根据 其 结果 执行 。 解 析 的 结果 包含 以 下 4 部 分 。 

。 子 进程 运行 所 需 的 参数 。 

e 子 进 程 运 行 时 的 classpath 列表 。 

。 系统 属性 的 映射 。 

e 子 进程 运行 时 的 主 类 。 
解析 之 后 调用 runMain 方法 ， 该 方法 中 除了 一 些 环境 设置 等 操作 外 ， 最 终 会 调用 解析 得 
到 的 childMainClass 的 main 方法 。 下 面 简单 分 析 一 下 prepareSubmitEnvironment 方法 通过 该 
方法 来 了 解 SparkSubmit 是 如 何 帮 助 底层 的 集群 管理 咒 和 部 署 模式 的 封装 。 接 下 来 以 不 同 集 
群 管理 器 和 部 署 模式 下 最 终 运 行 的 childMainClass 类 的 解析 为 主线 进行 分 析 。 

1) 当 部 署 模式 为 Client 时 ,将 childMainClass 设置 为 传人 的 mainClass， 对 应 代码 
如 下 。 



























































1. // 在 client 模式 ,直接 启动 应 用 程序 的 主 类 
2. // 同时 ,将 主 类 的 jar 包 和 添加 的 jars 包 ( 如 果 在 参数 中 设置 的 话 ) 
3. /都 添加 到 运行 时 的 classpath 中 
4. if(deployMode == CLIENT) | 

Ss childMainClass = args. mainClass 
6 

7 

8 

9 


























if( isUserJar( args. primaryResource ) ) | 
childClasspath += args. primaryResource 


| 


if( args. jars!= null) | childClasspath ++= args. jars. split("," )| 
10. if( args. childArgs!= null) | childArgs ++= args. childArgs | 


2) 当 集 群 管理 吉 为 Standalone 、 部 署 模式 为 Cluster 时 ， 根 据 提交 的 两 种 方式 将 childMa- 
inClass 分 别 设置 为 不 同 的 类 ， 同 时 将 传人 的 args. mainClass (提交 应 用 程序 时 所 设置 的 主 
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类 ) 及 其 参数 根据 不 同 集群 管理 需 与 部 署 模式 进行 转换 ， 并 封装 到 新 的 主 类 所 需 的 参数 中 。 
对 应 的 设置 如 表 3-3 所 示 。 





表 3-3 Standalone + Cluster 时 两 种 不 同 提 交 方 式 下 的 childMainClass 封装 











提交 方式 childMainClass 
REST 方式 (Spark 1.3+) "org. apache. spark. deploy. rest. RestSubmissionClient" 
传统 方式 "org. apache. spark. deploy. Client" 











表 3-3 中 ，REST (representational State Transfer， 表 述 性 状态 传递 ) 是 Roy Fielding 博士 
在 2000 年 他 的 论文 中 提出 来 的 一 种 软件 架构 网 格 。 

这 些 设置 的 主 类 相当 于 封装 了 应 用 程序 提交 时 的 主 类 ， 运 行 后 负责 向 Master 结 点 申请 
启动 提交 的 应 用 程序 。 

3) 当 集 群 管理 器 为 YARN 、 部 署 模式 为 Cluster 时 ，childMainClass 及 对 应 的 mainClass 
的 设置 如 表 3-4 所 示 。 














表 3-4 YARN + Cluster 时 childMainClass 下 的 childMainClass 封装 




















执行 对 象 childMainClass 被 封装 的 执行 类 (mainClass ) 
isPython "org. apache. spark. deploy PythonRunner" 
isR "org. apache. spark. deploy. yarn. Client" "org. apache. spark. deploy. RRunner" 
其 他 args. mainClass 








4) 当 集 群 管理 需 为 Mesos 、 部 署 模式 为 Cluster 时 ，childMainClass 及 对 应 的 mainClass 
的 设置 如 表 3-5 所 示 。 


表 3-5 Mesos + Cluster 时 childMainClass 下 的 childMainClass 封装 





执行 对 象 childMainClass 被 封装 的 执行 类 (mainClass) 





isPython 








" org. apache. spark. deploy. rest. RestSubmissionClient" 
其 他 args. mainClass 




















从 上 面 的 分 析 可 以 看 到 ， 当 使 用 Clinet 部 署 模式 进行 提交 时 ， 由 于 设置 的 childMainClass 
为 应 用 程序 提交 时 的 主 类 ， 因 此 是 直接 在 提交 点 执行 设置 的 主 类 ， 即 mainClass。 当 使 用 
Cluster 部 署 模式 进行 提交 时 ， 则 会 根据 具体 集群 管理 器 等 信息 使 用 相应 的 封装 类 。 这 些 封 
装 类 会 向 集群 申请 提交 应 用 程序 的 请 求 ， 然 后 在 由 集群 调度 分 配 得 到 的 结 点 上 启动 所 申请 的 
应 用 程序 。 

以 将 封装 类 设置 为 " org. apache. spark. deploy. Client " 为 例 ， 从 该 类 主人 口 main 方法 查 
看 ， 可 以 看 到 构建 了 一 个 ClientEndpoint 实例 ， 在 构建 该 实例 时 ， 会 将 提交 应 用 程序 时 设置 
的 mainClass 等 信息 封装 到 DriverDescription 实例 中 ， 然 后 发 送 到 Master， 申 请 执行 用 户 提交 
的 应 用 程序 。 

对 应 各 种 集群 管理 央 与 部 署 模式 的 组 合 ， 实 际 代码 中 的 处 理 细节 非常 多 。 这 里 仅仅 给 出 
了 一 种 源 代码 阅读 的 方式 ， 和 对 应 的 大 数据 处 理 一 样 ， 通 常 采 用 化 繁 为 简 的 方式 去 阅读 复杂 
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的 源 代码 。 比 如 这 里 在 理解 了 整个 大 框架 的 调用 过 程 后 ， 以 childMainClass 的 设置 作为 主线 
去 解读 源 代码 ， 相 应 的 ， 在 扩展 阅读 其 他 源 代码 时 ， 也 可 以 采用 这 种 方式 ， 以 某 种 集群 管理 
器 与 部 署 模式 为 主线 ， 详 细 阅 读 相 关 的 代码 。 最 后 ,在 了 解 各 种 组 合 的 处 理 细节 之 后 ， 通 过 
对 比 、 抽 和 象 等 方法 ， 对 整个 SparkSubmit 进行 归纳 总 结 即 可 。 

参考 3.4. 1 部 署 框 架 一 草 中 的 集群 部 署 组 件 图 (图 3-2) ， 可 以 看 到 提交 的 应 用 程序 的 
驱动 程序 (Driver Program) 部 分 对 应 包含 了 一 个 SparkContext 实例 。 因 此 接 下 来 从 该 实例 出 
发 ,解析 驱动 程序 在 不 同 的 集群 管理 右 的 部 署 细节 。 

4. SparkContext 解析 

在 详细 解析 SparkContext 实例 之 前 ， 首 先 来 看 下 SparkContext 类 的 注释 部 分 ， 具 体 如 下 。 


De A pr 























/** 
x* Spark 功能 的 主 和 人口 点 


* Main entry point for Spark functionality. A SparkContext represents the connection to a 





* Spark cluster,and can be used to create RDDs ,accumulators and broadcast variables on 
that cluster. 

* @ param config a Spark Config object describing the application configuration. Any 
* settings inthis config overrides the default configs as well as system properties. 

*/ 


SparkContext 类 是 Spark 功能 的 主 入 口 点 。 一 个 SparkContext 实例 代表 了 与 一 个 Spark 集 











群 的 连接 ， 并 且 通 过 该 实例 可 以 在 集群 中 构建 RDD 、 累 加 器 及 广播 变量 。SparkContext 实例 





的 构建 参数 config， 描 述 了 应 用 程序 的 Spark 配置 。 在 该 参数 中 指定 的 配置 属性 会 覆盖 默认 
的 配置 属性 及 系统 属性 。 

在 SparkContext 类 文件 中 ， 定 义 了 一 个 描述 集群 管理 需 类 型 的 单 例 对 象 SparkMasterRe- 
gex， 在 该 对 象 中 详细 给 出 了 当前 Spark 所 支持 的 各 种 集群 管理 器 类 型 ， 具 体 代码 如 下 。 





el A A ee 


10. 
是 
12. 
13. 


je 


14. 








信守 中 
* 定义 了 从 master 信息 中 抽取 集群 管理 器 类 型 的 一 个 正则 表达 式 集合 
* A collection of regexes for extracting information from the master string. 
*/ 

private object SparkMasterRegex | 

// 对 应 master 格式 如 local[ N] 和 local[ * ] 的 正则 表达 式 
// Regular expression used for localLN ] and locall * | master formats 


val LOCAL N_ REGEX =" "local\[ ([0-9] 2 | \* yy 太太 记 


// 对 应 master 格式 如 local[ N ,maxRetries ] 的 正则 表达 式 

// 这 种 集群 管理 需 类 型 用 于 具有 任务 失败 尝试 功能 的 测试 

// Regular expression for local[ N ,maxRetries | ,used in tests with failing tasks 
val LOCAL_N_FAILURES_REGEX ="""local\[([0 -9] + |\x)\s*,\s*([0-9]+) 
ls 
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15. // 一 种 模拟 Spark 集群 的 本 地 模式 的 正则 表达 式 

16. ”// 对 应 的 master 格式 如 local - cluster[ N ,cores ,memory] 

17. // Regular expression for simulating a Spark cluster of [ N ,cores ,memory | locally 

18. val LOCAL_CLUSTER_REGEX ="""l]local ~ cluster\[ \sx* ([0 -9] +)\sx,\s*([0—-9] O) 
+)\sx*,\s*([0-9] +)\s* ]""".r 





19. 

20. / 连接 Spark 部 署 集群 的 正则 表达 式 

21.  // Regular expression for connecting to Spark deploy clusters 
久光 val SPARK_REGEX ="""spark://(. * )""".r 

2 





24. ”// 连接 Mesos 集群 的 正则 表达 式 


25. // Regular expression for connection to Mesos cluster by mesos:// or mesos://2k:// ul 

















26. val MESOS_REGEX ="""mesos://(. * )""".r 

2 

28. ”// 使 用 Spark In MapReduce 方式 的 正则 表达 式 。 在 MapReduce 1 中 使 用 Spark 时 用 
29.  // Regular expression for connection to Simr cluster 

30. val SIMR_REGEX ="" "simr://(. * )""".r 

Sl 


在 SparkContext 类 中 的 主要 流程 可 以 归纳 如 下 。 
1) createSparkEnv: 创建 Spark 的 执行 环境 对 应 的 SparkEnv 实例 。 
对 应 代码 如 下 。 


1l. // Create the Spark execution environment( cache,map output tracker, etc) 
2. _env=createSparkEnv(_conf,isLocal, listenerBus) 


3. SparkEnv. set(_env) 


2) createTaskScheduler: 创建 作业 调度 器 实例 。 
对 应 代码 如 下 。 


1l. // Create and start the scheduler 

2. val (sched,ts) =SparkContext. createTaskScheduler( this, master) 
3.  _schedulerBackend = sched 

4. _taskScheduler =ts 








其 中 ，TaskScheduler 是 低层 次 的 任务 调度 器 ， 负 责任 务 的 调度 。 通 过 该 接口 提供 可 搬 拔 
的 任务 调度 需 。 每 个 TaskScheduler 负责 调度 一 个 SparkContext 实例 中 的 任务 ， 负 责 调度 上 层 
DAG 调度 如 中 每 个 Stage 提交 的 任务 集 (TaskSet) ， 并 将 这 些 任务 提交 到 集群 中 运行 ， 在 任 
务 提交 执行 时 可 以 使 用 失败 重 试 机 制 设置 失败 重 试 的 次 数 。 上 述 对 应 高 层 的 DAG 调度 器 的 
实例 构建 请 参见 下 一 步 。 

3) newDAGScheduler: 创建 高 层 Stage 调度 的 DAG 调度 器 实例 。 

对 应 代码 如 下 。 























_dagScheduler = new DAGScheduler( this) 





实例 对 应 的 类 
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DAGScheduler 是 高 层 调度 模块 ， 负 责 作 业 (Job) 的 Stage 拆 分 ， 以 及 最 终 将 Stage 对 应 
的 任务 集 提 交 到 低层 次 的 任务 调度 器 上 。 

下 面 基于 这 些 主要 流程 ， 针 对 SparkMasterRegex 单 例 对 象 中 给 出 的 各 种 集群 部 署 模式 进 
行 解析 。 对 应 不 同 集群 模式 下 ， 这 些 流程 中 构建 了 包括 TaskScheduler 与 SchedulerBackend 的 
不 同 的 具体 子 类 ， 所 构建 的 相关 实例 具体 如 表 3-6 所 示 。 


表 3-6 各 种 情况 下 TaskScheduler 与 SchedulerBackend 的 不 同 的 具体 子 类 





备 注 








Local[ * ] ,Local[ N] 





_taskScheduler: TaskSchedulerImpl 
_schedulerBackend :LocalBackend 





最 简单 的 本 地 模式 
这 种 本 地 模式 下 ， 任 务 的 失败 重 试 次 数 为 1， 
即 失败 不 重 试 











指定 线程 个 数 的 本 地 模式 ， 指 定 方式 及 最 终 
的 线程 数 如 下 : 
* ] : 当前 处 理 器 的 个 数 





1 ) Local[ 

2) Local[N]: 指定 的 N 

这 种 本 地 模式 下 ， 任 务 的 失败 重 试 次 数 为 1， 
即 失败 不 重 试 











指定 线程 个 数 及 失败 重 试 次 数 的 本 地 模式 ， 
仅 比 上 一 种 本 地 模式 多 了 一 个 失败 重 试 次 数 的 
设置 ， 对 应 为 M 

















_taskScheduler: TaskSchedulerImpl 
_schedulerBackend :SparkDeploySchedulerBackend 


本 地 伪 分 布 式 集群 ， 由 于 本 地 模式 下 没有 集 
群 ， 因 此 需要 构建 一 个 用 于 模拟 集群 的 实例 : 
localCluster = new LocalSparkCluster 

对 应 的 3 个 参数 如 下 : 

numSlaves: 模拟 集群 的 Slave 结 点 个 数 

coresPerSlave: 模拟 集群 的 各 个 Slave 结 点 上 
的 内 核 数 

memoryPerSlave: 模拟 集群 的 各 个 Slave 结 点 
上 的 内 存 大 小 









































Spark Standalone 对 应 Spark 原生 的 完全 分 布 
因此 ， 此 种 方式 下 不 需要 像 上 面 的 本 地 伪 分 
布 式 集群 那样 构建 一 个 虚拟 的 本 地 集群 


























_taskScheduler:YarmScheduler 


_schedulerBackend :YarnClientSchedulerBackend 


YARN 集群 管理 器 + Client 部 署 





_ taskScheduler:YarnClusterScheduler 
_schedulerBackend:YarnClusterSchedulerBackend 











YARN 集群 管理 器 + Cluster 部 署 





_taskScheduler: YamScheduler 


_schedulerBackend :CoarseMesosSchedulerBackend 、 


MesosSchedulerBackend 


_schedulerBackend 具体 的 实例 根据 资源 分 配 
的 请 求 设置 








_taskScheduler: TaskSchedulerImpl 
_schedulerBackend :LocalBackend 





Spark InMapReduce 1 的 集群 部 署 





与 TaskScheduler 与 SchedulerBackend 不 同 的 是 ， 在 不 同 集群 模式 中 ， 应 用 程序 的 高 层 调 
度 右 DAGScheduler 的 实例 是 相同 的 ， 即 对 应 在 Spark on YARN 与 Mesos 等 集群 管理 需 中 ， 应 
用 程序 内 部 的 高 层 Stage 调度 是 相同 的 。 
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|_Section | 
Local 与 Local - Cluster 部 署 


对 于 分 布 式 集 群 ， 通 常 都 会 提供 一 种 方便 初学 者 入 门 学 习 和 测试 的 部 署 模式 ， 也 就 是 在 
Hadoop 框架 中 常 说 的 Local (本 地 ) 模式 。 同 样 的 ，Spark 框架 也 不 例外 ， 而 且 相 对 于 其 他 
框架 ， 比 如 Hadoop ，Spark 框架 提供 了 更 丰富 的 Local 模式 。 

在 进一步 解析 之 前 ， 首 先 来 看 下 SparkSubmit 提交 应 用 程序 时 ， 一 些 不 支持 的 组 合 形式 ， 
对 应 代码 如 下 。 

















1. private| deploy | def prepareSubmitEnvironment( args :SparkSubmitArguments ) 


3. case(LOCAL ,CLUSTER ) => 
printErrorAndExit( " Cluster deploy mode is not compatible with master\"local\"") 
4. 


即 ， 在 使 用 Local 与 Local - Cluster 这 两 种 Local 方式 时 ， 不 支持 以 CLUSTER 的 部 署 模 
式 提交 应 用 程序 。 

了 解 SparkContext 执行 的 主要 流程 后 ， 再 以 Local 与 Local - Cluster 部 署 为 主线 ， 分 析 本 
地 集群 部 署 模 式 下 的 处 理 细节 。 

可 以 从 前 面 的 分 析 中 抽取 出 本 地 模式 部 署 的 TaskScheduler 与 SchedulerBackend 的 具体 子 
类 的 实例 构建 信息 ， 如 表 3-7 所 示 。 

表 3-7 Local 模式 部 署 时 的 TaskScheduler 与 SchedulerBackend 的 具体 子 类 
部 署 模式 ( Master) 实例 对 应 的 类 备 注 


呈 最 简单 的 本 地 模式 
这 种 本 地 模式 下 ， 任 务 的 失败 重 试 次 数 为 1， 即 
失败 不 重 试 
指定 绥 程 不 殊 的 末 韦 模式， 指定 方式 及 最 炙 的 屋 
程 数 如 下 : 
_taskScheduler: TaskSchedulerImpl 1) Locall * ] : 当前 处 理 器 的 个 数 
Local[ * ,M] 、 _schedulerBackend :LocalBackend 2) Local[N]: 指定 的 NN 
Locall NM] 这 种 本 地 模式 下 ， 任 务 的 失败 重 试 次 数 为 1， 即 
失败 不 重 试 
指定 线程 个 数 及 失败 重 试 次 数 的 本 地 模式 ， 仅 比 
上 一 种 本 地 模式 多 了 一 个 失败 重 试 次 数 的 设置 ， 对 
应 为 M 
本 地 伪 分 布 式 集群 ， 由 于 本 地 模式 下 没有 集群 ， 
因此 需要 构建 一 个 用 于 模拟 集群 的 实例 : localClus- 
ter = new LocalSparkCluster 


_taskScheduler: TaskSchedulerIm- 对 应 的 3 个 参数 如 下 ， 


Local - Cluste laves, core- |pl a , | 

ocal — Cluster[ numSlaves, core-|p numslaves， 模 拟 集群 的 Slave 结 点 个 数 

sPerSlave, memoryPerSlave | _schedulerBackend : SparkDeploy- coresPerSlave， 模拟 集群 的 各 个 Slave 结 点 上 的 内 

SchedulerBackend 核 数 
六 


memoryPerSlave: 模拟 集群 的 各 个 Slave 结 点 上 的 
内 存 大 小 
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本 地 部 署 模式 可 以 分 为 本 地 模式 和 本 地 伪 分 布 式 模式 ， 其 中 ， 本 地 模式 又 分 3 种 ， 而 
Local - Cluster 这 种 则 对 应 本 地 伪 分 布 式 模式 。 在 3 种 本 地 模式 中 ， 内 部 实现 的 实例 相同 ， 
仅仅 是 启动 的 线程 数 与 任务 失败 重 试 的 次 数 不 同 ; 本 地 伪 分 布 式 模式 中 ， 通 过 提供 与 Spark 
Suandalone 部 署 集群 对 应 的 信息 来 模拟 完全 分 布 式 的 集群 

下 面 分 别针 对 这 几 种 本 地 部 署 模式 进行 分 析 。 








区 吾 Local 部 署 ) 


在 该 模式 下 ， 使 用 一 个 工作 线程 执行 计算 任务 ， 并 且 在 任务 失败 时 不 会 重新 计算 ， 即 在 
失败 重启 机 制 中 使 用 重启 次 数 为 1。 对 应 的 控制 变量 参考 代码 如 下 。 





1. / 当 本 地 运行 时 ,任务 失败 时 不 会 重新 执行 
2. // When running locally, don t try to re — execute tasks on failure 


3. val MAX LOCAL TASK_FAILURES=1 


Local[*] 与 Local[ N] 部 署 


该 模式 相当 于 在 Local 部 署 的 基础 上 增加 了 线程 个 数 的 控制 。 

1) Locall * ] 模 式 ， 线 程 个 数 取决 于 本 机 的 处 理 器 个 数 ， 逻 辑 上 保证 一 个 处 理 咒 对 应 一 
个 处 理 线程 。 

2) LocalLN] 模 式 ， 直 接 指定 了 使 用 的 线程 个 数 为 N。 

在 这 两 种 模式 下 ， 也 不 会 启动 任务 失败 重 试 的 机 制 ， 对 应 控制 参数 同 Local 模式 。 


Local[ * ,M] 与 Local[N,M] 部 署 


在 该 模式 下 ， 除 了 和 上 一 种 类 似 的 线程 个 数控 制 之 外 ， 还 增加 了 任务 失败 重 试 机 制 的 失 
败 重 启 次 数 的 配置 ， 即 可 以 指定 任务 失败 重 试 的 最 大 次 数 为 M。 
在 前 3 种 本 地 模式 中 ，SchedulerBackend 的 实现 都 是 LocalBackend， 该 类 的 注释 如 下 。 














/水 水 
* 在 以 下 情况 时 使 用 LocalBackend :运行 一 个 Spark 的 本 地 模式 ,其 中 ， 
# executor .backend 和 master 运行 在 同一 个 JVM 进程 中 


* LocalBackend is used when running a local version of Spark where the executor ,backend ， 





* and master all run in the same JVM. It sits behind a TaskSchedulerImpl and handles 
* launching tasks on a single Executor( created by the LocalBackend )running locally. 
4 

private| spark | class LocalBackend( 


00 


conf: SparkConf, 
10. scheduler:TaskSchedulerImpl, 


11. val totalCores : Int ) 
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在 此 简单 给 出 内 部 实现 流程 的 解析 ， 具 体 步 又 如 下 。 

1) 对 应 的 初始 化 代码 在 前 面 提 到 的 SparkContext 类 中 主要 流程 的 createTaskScheduler 方 
法 中 ,构建 TaskScheduler 实例 (这 里 具体 子 类 为 TaskSchedulerImpl) 后 ， 在 初始 化 该 实例 
时 传人 同时 构建 的 SchedulerBackend 实例 (这 里 具体 子 类 为 LocalBackend) 。 

2) 构建 出 TaskScheduler 实例 后 ， 会 调用 实例 的 start 方法 ,在 该 方法 中 首先 会 调用 
SchedulerBackend 的 start 方法 。 

3) 在 SchedulerBackend 的 start 方法 中 会 构建 出 一 个 LocalEndpoint 实例 ， 在 该 实例 中 就 
会 实例 化 出 一 个 Executor，Executor 实例 负责 具体 的 任务 执行 。 

4) 之 后 就 是 TaskScheduler 进行 作业 调度 ， 调 用 SchedulerBackend 的 reviveOffers( ) 方 
法 ， 然 后 由 该 方法 向 LocalEndpoint 实例 发 送 ReviveOffers 消息 。 

5) 最 终 在 LocalEndpoint 实例 处 理 ReviveOffers 消息 时 启动 Task， 其 他 处 理 类 似 。 对 应 
Task 的 启动 代码 如 下 。 






































1. def reviveOffers( ) | 

2 val offers = Seq( new WorkerOffer( localExecutorld ,localExecutorHostname ,freeCores ) ) 

于 for( task <— scheduler. resourceOffers ( offers ) . flatten ) | 

4. // 在 Executor 中 会 使 用 线程 池 的 方式 调度 任务 ,而 对 应 的 作业 调度 是 通过 

Sk /7/ 判断 当前 可 用 Cores 个 数 是 否 符合 每 个 任务 (Task) 所 需 的 Cores 个 数 。 

6. // 当 符 合 该 条 件 时 更 新 当前 可 用 Cores 数 freeCores ,然后 启动 任务 (Task) 

TE freeCores -= scheduler. CPUS_PER_TASK 

8. executor. launchTask ( executorBackend, taskld = task.taskId，attemptNumber = 
task. attemptNumber， 

9. task. name , task. serializedTask ) 

10. } 

i 


其 中 ，Task 的 调度 控制 代码 参考 TaskSchedulerImpl 的 resourceOfferSingleTaskSet 方法 。 
上 述 3 种 Local 的 部 署 模式 可 以 通过 图 3-1 来 加 深 理 解 。 
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图 3-1 3 种 Local 的 部 署 模式 图 
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其 中 ，TaskScheduler 与 SchedulerBackend 的 具体 子 类 的 具体 子 类 分 别 为 TaskSchedulerImpl 
与 LocalBackend， 上 有 具体 的 Task 仍然 在 Executor 中 执行 。 


Local - Cluster[ S,C,M] 部 署 





格式 如 Local - Cluster [numSlaves ，coresPerSlave ，memoryPerSlave] 的 这 种 模式 称 为 本 
地 伪 分 布 式 部 署 模式 ， 由 于 当前 使 用 的 是 本 地 部 署 模式 ， 因 此 不 存在 所 谓 的 集群 ， 所 以 在 模 
拟 伪 分 布 式 部 署 模式 时 ， 需 要 构建 出 一 个 模拟 的 集群 模式 。 模 拟 的 集群 模式 在 代码 中 对 应 
LocalSparkCluster 实例 。 

在 本 地 伪 分 布 式 部 署 模式 中 ， 构 建 的 作业 调度 器 同 其 他 3 种 本 地 模式 一 样 ， 也 是 实例 化 
具体 子 类 TaskSchedulerImp1， 但 同时 构建 的 SchedulerBackend 实例 是 和 真实 的 Spark Standa- 
lone 集群 是 一 样 的 ， 也 是 实例 化 了 SparkDeploySchedulerBackend 子 类 。 这 说 明 本 地 伪 分 布 式 
部 署 模式 仅仅 在 集群 组 件 构 建 的 方式 上 有 所 差异 ， 其 他 方面 都 是 相同 的 。 

对 应 的 集群 模拟 可 以 查看 LocalSparkCluster 的 start 方法 ， 其 中 构建 了 Master 和 多 个 
Worker 实例 来 模拟 分 布 式 集群 。 模 拟 时 使 用 的 参数 也 是 参考 Spark Standalone 集群 ， 通 过 
numSlaves 指定 模拟 集群 中 的 Slaves 结 点 个 数 ， 通 过 coresPerSlave 指定 模拟 集群 中 各 个 Slave 
结 点 上 的 内 核 数 ， 以 及 通过 memoryPerSlave 指定 模拟 集群 中 各 个 Slave 配置 的 内 存 大 小 。 

另外 ， 本 地 模式 在 其 他 细节 方面 的 影响 ， 可 以 查看 SparkContext 中 的 本 地 模式 控制 变量 
的 设置 ， 对 应 变量 定义 的 代码 如 下 。 






































def isLocal: Boolean = (master == "local" || master. startsWith( "local[" ) ) 


通过 查看 isLocal 变量 的 代码 ， 即 可 找到 与 本 地 模式 相关 的 内 容 。 





Spark Standalone 部 署 
部 署 框架 








在 详细 解析 之 前 ， 首 先 来 看 一 下 集群 部 署 组 件 图 ， 如 图 3-2 所 示 。 











图 3-2 集群 部 署 组 件 医 
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其 中 各 个 术语 及 相关 术语 的 描述 如 下 。 

1) Driver Program: 运行 Application 的 main 函数 并 且 新 建 SparkContext 实例 的 程序 ， 称 
为 驱动 程序 (Driver Program )。 通 常 可 以 使 用 SparkContext 来 代表 驱动 程序 (Driver 
Program ) 。 

2) Cluster Manager: 集群 管理 需 (Cluster Manager) ， 是 集群 资源 管理 的 外 部 服务 ， 在 
Spark 上 现在 主要 有 Standalone 、YARN 和 Mesos 等 3 种 集群 资源 管理 器 ，Spark 自 带 的 Stan- 
dalone 模式 能 够 满足 绝 大 部 分 纯粹 的 Spark 计算 环境 中 对 集群 资源 管理 的 需求 ， 基 本 上 只 
在 集群 中 运行 多 套 计算 框架 时 才 建 议 考虑 YARN 和 Mesos。 

3) Worker Node: 集群 中 可 以 运行 Application 代码 的 工作 结 点 ( Worker Node) ， 相 当 于 
Hadoop 的 Slave 结 点 。 

4) Executor: 在 Worker Node 上 为 Application 启动 的 一 个 工作 进程 ， 在 进程 中 负责 任务 
(Task) 的 运行 ， 并 且 负 责 将 数据 存放 在 内 存 或 磁盘 上 ， 在 Executor 内 部 通过 多 线程 的 方式 
( 即 线程 池 ) 并 发 处 理应 用 程序 的 具体 任务 。 

每 个 Application 都 有 各 自 独 立 的 Executors ， 因 此 应 用 程序 之 间 是 相互 隔离 的 。 

5) Task: 任务 (Task) 是 指 被 Driver 送 到 Executor 上 的 工作 单元 ， 通 常情 况 下 一 个 
任务 (Task) 会 处 理 一 个 Partition 的 数据 ， 每 个 Partition 一 般 为 一 个 HDFS 的 Block 块 的 
大 小 。 

6) Application: Application 是 创建 了 SparkContext 实例 对 象 的 Spark 用 户 程 序 ， 包 含 了 
一 个 Driver program 和 集群 中 多 个 Worker 上 的 Executor。 

7) Job: 和 Spark 的 action 相对 应 ， 每 一 个 action ， 如 count、savaAsTextFile 等 都 会 对 应 
一 个 Job 实例 ， 每 个 Job 会 被 拆 分 成 多 个 Stages， 一 个 Stage 中 包含 一 个 任务 集 (TaskSet ) ， 
任务 集中 的 各 个 任务 (Task) 通过 一 定 的 调度 机 制 发 送 到 工作 单位 (Executor) 上 并 行 
执行 。 


应 用 程序 的 部 署 ) 


和 其 他 常见 的 分 布 式 集群 类 似 ，Spark Standalone 集群 的 部 署 也 是 采用 典型 的 Master/ 
Slave 架构 。 其 中 ，Master 结 点 负责 整个 集群 的 资源 管理 与 调度 ，Worker 结 点 (也 可 以 称 
Slave 结 点 ) 在 Master 结 点 的 调度 下 启动 Executor， 负 责 执行 具体 工作 (包括 应 用 程序 及 应 
用 程序 提交 的 任务 ) 。 

从 前 面 的 分 析 中 抽取 出 Spark Standalone 模式 部 署 的 TaskScheduler 与 SchedulerBackend 
具体 子 类 的 实例 构建 信息 ， 如 表 3-8 所 示 。 









































表 3-8 Spark Standalone 模式 部 署 具体 子 类 的 构建 





部 署 模式 ( master) 实例 对 应 的 类 备 ” 注 








" 村 的 
taskScheduler: TaskSchedulerImpl Spak Standalone 对 应 Spark 原生 的 完全 分 布 
Spark Standalone schedulerBackend: SparkDeployScheduler- 式 集群 。 
。 | enG :Spee ep oy9e eu en | 因此， 此 种 方式 下 不 需要 像 上 面 的 本 地 伪 分 


Backend 























布 式 集群 那样 构建 一 个 虚拟 的 本 地 集群 
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下 面 以 提交 请 求 的 行为 为 例 ， 结 合 应 用 程序 提交 时 所 使 用 的 不 同 部 署 模式 ， 给 出 详细 的 
框架 及 其 描述 ， 对 应 在 框架 中 的 其 他 请 求 与 此 类 似 ， 可 以 自行 解析 。 
1， 以 Client 的 部 署 模式 提交 应 用 程序 














在 Client 的 部 署 模式 提交 时 ， 直 接 在 提交 点 运行 应 用 程序 ， 即 对 应 的 驱动 程序 是 在 当前 
结 点 启动 的 。 启 动 一 个 应 用 程序 后 ， 就 涉及 各 个 相关 的 方面 ， 包 含 应 用 运行 的 环境 、 应 用 元 
数据 的 清理 、 状 态 监 听 、DAG 调度 、 任 务 调度 等 。 

对 应 的 部 署 与 执行 框架 如 图 3-3 所 示 。 
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Master 结 点 
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RPC 通 信 终 端 
类 的 实例 (包含 进程 启动 的 主 类 ) 
图 3-3 ”Client 部 署 模式 下 的 部 署 与 执行 框架 
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如 图 3-3 所 示 ， 在 驱动 程序 (Driver Program) 内 部 会 构建 一 个 SparkContext 实例 ， 在 
前 面 章节 中 已 经 分 析 过 ， 在 SparkContext 实例 的 主要 流程 中 ， 会 构建 出 用 于 任务 调度 的 
TaskScheduler 实例 、 用 于 DAG 调度 的 DAGScheduler 实例 ， 以 及 作为 TaskSchedulerImpl 底 
层 的 一 个 可 插 拔 的 调度 系统 终端 的 SparkDeploySchedulerBackend 实例 。 由 于 调度 系统 后 续 
会 用 单独 一 章 的 篇 幅 进 行 解析 ， 因 此 这 里 仅仅 给 出 简单 的 部 署 与 交互 过 程 ， 具 体 过 程 
如 下 。 

1) 在 SparkContext 构建 出 SparkDeploySchedulerBackend 实例 后 ， 调 用 该 实例 的 start 方 
法 ， 关 键 代码 如 下 。 











1. override def start( ) | 
2: super. start( ) 
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launcherBackend. connect( ) 


3 
4 

5 // 封装 的 命令 ,该 命令 发 送 到 Worker 结 点 ,并 根据 获取 的 资源 启动 后 ,相当 于 
6. // 打开 了 一 个 通信 通道 
7 
8 
9 





val command = Command( " org. apache. spark. executor. CoarseCrainedExecutorBackend'" ， 
args ,SC. executorEnvs ,classPathEntries ++ testingClassPath ,libraryPathEntries ,javaOpts ) 
val appUIAddress = sc. ui. map(_. appUIAddress ). getOrElse("") 
10. val coresPerExecutor = conf getOption( " spark. executor. cores" ). map( _. toInt) 
11. ”// 通过 ApplicationDescription 将 command 封装 起 来 
12. val appDesc = new ApplicationDescription( sc. appName ,maxCores ,sc. executorMemory, 


13. command ,appUIAddress ,sc. eventLogDir ,sc. eventLogCodec , coresPerExecutor) 











15. /7 构建 一 个 作为 应 用 程序 客户 端的 AppClient 实例 ,并 将 this 设置 为 该 实例 的 监听 
16. // 需 ,AppClient 实例 内 部 会 将 Executor 端的 消息 转发 给 this 


17. client = new AppClient( sc. env. rpcEnv, masters ,appDesc ,this ,conf) 














18. client. start( ) 

19. launcherBackend. setState( Spark AppHandle. State. SUBMITTED) 
20. waitForRegistration( ) 

2 launcherBackend. setState( Spark AppHandle. State. RUNNING) 
2 } 


其 中 ，AppClient 实例 在 调用 方法 start 时 ， 会 构建 一 个 RPC 通信 终端 ， 即 ClientEndpoint 
实例 ， 实 例 化 后 再 自动 调用 onStart( ) ， 这 时 就 会 将 封装 的 ApplicationDescription 实例 进一步 
封装 到 消息 RegisterApplication 的 实例 中 ， 然 后 由 该 RPC 通信 终端 将 该 信息 发 送 到 Master 的 
RPC 通信 终端 。 

2) Master 的 RPC 通信 终端 在 收 到 RegisterApplications 消息 后 ， 通 过 资源 调度 方法 ， 最 
终 会 调用 launchExecutor 方法 ， 在 该 方法 中 再 向 调度 所 分 配 到 的 Worker 结 点 的 RPC 通信 终 
端 发 送 LaunchExecutor 消息 。 

3) Worker 的 RPC 通信 终端 在 收 到 LaunchExecutor 消息 后 ， 会 实例 化 ExecutorRunner 对 
象 ， 然 后 启动 一 个 线程 ， 在 线程 中 解析 RegisterApplications 消息 封装 的 ApplicationDescription 
实例 所 携带 的 Command 实例 ， 也 就 是 前 面 封装 的 CoarseGrainedExecutorBackend 类 ， 最 后 启 
动 CoarseGrainedExecutorBackend 类 的 进程 。 进 程 的 入 口 就 是 CoarseGrainedExecutorBackend 伴 
生 对 象 的 main 函数 。 

4) 在 入口 处 ， 即 CoarseGrainedExecutorBackend 伴生 对 象 的 main 函数 中 ， 会 解析 参数 ， 
然后 调用 run 函数 ， 在 该 run 函数 中 会 构建 CoarseGrainedExecutorBackend 实例 ， 也 就 是 构建 
一 个 RPC 通信 终端 。Run 方法 中 的 关键 代码 如 下 。 

































































1. env. rpcEnv. setupEndpoint( "Executor" ,new CoarseGrainedExecutorBackend( 
2 env. TpcEnv ,driverUzl ,executorId ,sparkHostPort , cores ,userClassPath , env ) ) 


3. workerUrl. foreach | url => 





© 
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4. env. rpcEnv. setupEndpoint( "WorkerWatcher" ,new WorkerWatcher( env. rpcEnv ,url) ) 


| 


其 中 ，driverUrl 是 封装 CoarseGrainedExecutorBackend 到 Command 时 设置 的 ， 可 以 回 到 
前 面 SparkDeploySchedulerBackend 实例 的 start 方法 ， 在 构建 Command 之 前 ， 设 置 了 一 些 参 
数 ， 对 应 的 代码 如 下 。 


1 . // The endpoint for executors to talk to us 

2 val driverUrl = rpcEnv. uriOf( SparkEnv. driverActorSystemName, 

3 RpcAddress ( sc. conf. get ( " spark. driver. host" ), sc. conf. get ( " spark. driver. port" ) 
. toInt) ， 

4. CoarseGrainedSchedulerBackend. ENDPOINT_NAME) 

5 val args = Seq( 

6. " —— driver — url" ,driverUrl, 

7 " ——executor -id" ," | |EXECUTOR_ID} }",， 

8 " ——hostname" ," | | HOSTNAME} }", 

9. " ——cores"," ||CORES}}", 

10. "app—id","||APP_ID}}", 

11. " ——worker—url","||WORKER_URL|}") 


其 中 ,第 4、6 行 就 是 封装 的 与 CoarseGrainedExecutorBackend 进行 通信 的 终端 及 其 对 应 
参数 的 选项 名 称 ， 也 就 是 前 面 的 CoarseGrainedSchedulerBackend 实例 的 driverEndpoint: Driv- 
erEndpoint 成 员 ， 对 应 在 Spark Standalone 部 署 模式 下 ， 就 是 具体 子 类 SparkDeployScheduler- 
Backend 。 

5) 对 应 CoarseGrainedExecutorBackend 的 RPC 通信 终端 ， 在 实例 化 时 自动 调用 on- 
Start 方法 。 在 该 方法 中 间 driverUrl 发 送 RegisterExecutor 消息 。 这 里 的 driverUrl 就 是 上 
一 步 分 析 得 到 的 驱动 程序 端的 SparkDeploySchedulerBackend 的 RPC 通信 端口 driver- 
Endpoint。 

6) SparkDeploySchedulerBackend 实例 收 到 RegisterExecutor 消息 时 ， 表 示 当 前 有 可 用 资 
源 注册 上 来 ， 此 时 即 可 开始 作业 的 调度 。 具 体 的 调度 过 程 可 以 参考 本 书 的 第 4 章 。 





[0 说 明 : 分 布 式 消息 间 的 调度 是 建立 在 消息 事件 的 基础 上 的 ， 可 以 通过 列举 所 有 的 RPC 通信 终端 ( 系统 
名 + 终端 名 ) 和 各 个 终端 之 间 交 互 的 信息 这 两 个 方面 ， 来 理 清 整个 分 布 式 集群 中 各 个 组 件 之 间 和 内 部 
的 交互 逻辑 ， 进 而 把 握 整 个 调度 机 制 。 





2. 以 Cluster 的 部 署 模式 提交 应 用 程序 

结合 “3.2. 2 应 用 部 署 的 源 代 码 解析 ”中 的 内 容 来 看 ， 在 Cluster 的 部 署 模式 提交 时 ， 
Spark 会 将 应 用 程序 封装 到 指定 的 类 中 ， 由 该 类 负责 向 集群 申请 提交 应 用 程序 的 执行 。 即 在 
Cluster 部 署 模式 提交 时 ， 通 过 向 Master 申请 执行 应 用 程序 ， 然 后 由 Master 负责 调度 分 配 一 
个 Worker 结 点 ， 并 向 该 结 点 发 送 启动 应 用 程序 的 消息 ， 应 用 程序 启动 后 的 执行 流程 ， 与 在 
该 Worker 结 点 上 直接 以 Client 部 署 模式 提交 应 用 程序 的 执行 流程 是 一 样 的 ， 只 是 在 此 之 前 
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需要 先 调度 得 到 该 Worker 结 点 ， 并 在 该 结 点 启动 应 用 程序 。 由 于 在 申请 到 资源 并 启动 提交 
的 应 用 程序 之 后 ， 这 一 执行 框架 和 Client 部 署 模式 下 是 一 样 的 ， 因 而 在 此 仅 关注 将 应 用 程序 
封装 到 指定 类 ， 并 与 集群 Master 进行 交互 的 执行 框架 。 
再 次 查看 对 应 封装 的 类 ， 如 表 3-9 所 示 。 人 
表 3-9 ”Cluster 的 部 署 模式 提交 时 具体 封装 的 子 类 


提交 方式 childMainClass 








REST 方式 (Spark 1.3+) " org. apache. spark. deploy. rest. RestSubmissionClient" 








传统 方式 " org. apache. spark. deploy. Client" 





下 面 根据 不 同 的 提交 方式 分 析 提 交 应 用 程序 的 请 求 ， 对 应 其 他 的 请 求 行为 ， 比 如 kK 应 
用 程序 或 获取 应 用 程序 的 状态 等 ， 都 可 以 借鉴 提交 应 用 的 执行 框架 的 解析 来 加 深 理解 。 








说 明 : 注意 Client 与 Cluster 两 种 部 署 模式 下 ， 首 次 提交 申请 的 对 象 是 不 同 的 ，Clinet 时 是 直接 提交 应 用 
程序 的 申请 ，Cluster 时 会 先 提 交 应 用 程序 本 身 的 申请 ， 结 合 前 面 的 部 署 框架 ( 见 图 3-2)， 通常 应 用 程 
序 也 称 为 驱动 程序 (Driver Program) ， 因 此 该 部 署 模式 下 首次 提交 的 申请 对 应 的 是 Driver 的 申请 ， 在 代 
码 中 这 两 种 模式 分 别 对 应 的 申请 的 描述 信息 为 ApplicationDescription 与 DriverDescription。 








(1) 提交 方式 为 REST 方 式 (Spark 1.3 + ) 

当 提交 方式 为 REST 方式 (Spark 1.3 + ) 时 ，Spark 会 将 应 用 程序 的 主 类 等 信息 封装 到 
RestSubmissionClient 类 中 ， 由 该 类 负责 向 RestSubmissionServer 发 送 提交 应 用 程序 的 请 求 ， 而 
RestSubmissionServer 接收 到 应 用 程序 提交 的 请 求 之 后 ， 会 向 Master 发 送 RequestSubmitDriver 
消息 ， 然 后 由 Master 根据 资源 调度 策略 ， 启 动 集群 中 相应 的 Driver， 执 行 提交 的 应 用 程序 。 
详细 的 执行 框架 如 图 3-4 所 示 。 














RestSubmissionClient RestSubmissionServer 









1.constructSubmitRequest 3.postjson StandaloneSubmitRequestServlet 
2.createSubmission 
4.doPost 


5.handleSubmit 


结 点 
6.RequestSubmitDriver 
Master 
7.createDriver 
8.schedule 









9.LaunchDriver 结 点 


workerEndpoint 
CD 一 一 一 RPC 通 信 终 端 





类 的 实例 〈 包 含 进程 启动 的 主 类 ) 











图 3-4 Cluster 部 署 模式 下 的 部 署 与 执行 框架 


为 了 体现 各 个 组 件 间 的 部 署 关 系 ， 这 里 以 框架 图 的 形式 进行 描述 ， 相 应 的 ， 可 以 从 时 序 
图 的 角度 去 理解 各 个 类 或 组 件 之 间 的 交互 关系 。 其 中 组 件 Master 和 Worker 的 标注 在 方 框 的 
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左上 角 ， 其 他 方 框 表示 一 个 具体 的 实例 。 





其 中 ，RestSubmissionClient 是 提交 应 用 程序 的 客户 端 处 ， 是 对 提交 的 应 用 程序 进行 封装 
的 类 。 之 后 各 个 组 件 间 的 交互 流程 分 析 如 下 。 

1) 第 1 步 constructSubmitRequest， 就 是 在 RestSubmissionClient 实例 中 ， 根 据 提 交 的 应 
用 程序 信息 构建 出 提交 请 求 。 

2) 然后 继续 第 2 步 createSubmission ， 在 该 步骤 中 向 RestSubmissionServer 发 送 post 请 
求 ， 即 图 3-4 中 对 应 的 第 3 步 (注意 ,实际 上 是 在 第 2 步 中 调用 ) 。 

3 ) RestSubmissionServer 接收 到 post 请 求 后 ， 由 对 应 的 Servlet 进行 处 理 ， 这 里 对 应 为 
StandaloneSubmitRequestServlet。 即 开始 第 4 步 ， 调 用 doPost， 发 送 Post 请 求 。 

4) doPost 中 继续 第 5 步 handleSubmit， 开 始 处 理 提 交 请 求 。 在 处 理 过 程 中 ， 向 Master 的 
RPC 终端 发 送 消息 RequestSubmitDriver， 对 应 图 3-4 中 的 第 6 步 。 

5) Master 接收 到 该 消息 后 ， 执 行 第 7 步 createDriver， 创 建 Driver， 创 建 时 需要 由 Master 
的 调度 机 制 (对 应 第 8 步 shedule) 获取 分 配 的 资源 后 ， 向 Worker (这 些 Worker 启动 时 会 
注册 到 Master 上 ) 的 RPC 终端 发 送 LaunchDriver 消息 。 








封装 的 应 用 程序 。 





注意 : 从 上 面 的 部 署 框架 及 其 术语 解析 部 分 可 以 知道 ， 由 于 提交 的 应 用 程序 在 main 部 分 包含 了 Spark- 
Context 实例 ， 因 此 也 称 之 为 Driver Program， 即 驱动 程序 。 因 此 在 框架 中 ， 对 应 在 Master 和 Worker 处 都 
使 用 Driver， 而 不 是 Application (应 用 程序 ) 。 











其 中 主要 的 源 代 码 及 其 分 析 如 下 。 
1) RestSubmissionClient 的 run 方法 的 代码 如 下 。 


]. /A/#** 

2 * Submit an application ,assuming Spark parameters are specified through the given config. 
3 * This is abstracted to its own method for testing purposes. 

4. 米 / 

S: def run( 

6. appResource: String, 

Ws mainClass: String, 

8. appArgs: Array[ String | ， 

9. conf: SparkConf, 

10. env: Map| String, String | = Map( ) ) :SubmitRestProtocolResponse = | 
11. val master = conf. getOption( " spark. master" ). getOrElse | 

i throw new IllegalArgumentException(" spark. mastet must be set. " ) 
13. | 

14. val sparkProperties = conf. getAll. toMap 

3 





16. /创建 一 个 Rest 提交 客户 端 


17. val client = new RestSubmissionClient( master) 
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18. 

19. // 封装 应 用 程序 的 相关 信息 ,包括 主 资源 . 主 类 等 

20. val submitRequest = client. constructSubmitRequest( 

Zi appResource ,mainClass , appArgs ,sparkProperties , env ) OO 
2 

2 // Rest 提交 客户 端 开 始 创建 Submission， 

2 // 创建 过 程 中 向 RestSubmissionServer 发 送 post 请 求 

25. client. createSubmission( submitRequest ) 

26. } 


2) 收 到 提交 的 Post 请 求 之 后 ，StandaloneSubmitRequestServlet 向 Master 的 RPC 终端 发 
送 请 求 ， 代码 如 下 。 



































I /** 

2 * Handle the submit request and construct an appropriate response to return to the client. 
各 * 

4. * This assumes that the request message is already successfully validated. 

3 * If the request message is not of the expected type, return error to the client. 

6. */ 

A protected override def handleSubmit( 

8. requestMessagejson : String ， 

由 requestMessage : SubmitRestProtocolMessage , 

10. responseServlet: HttpServletResponse) :SubmitRestProtocol Response = 

11. requestMessage match | 

12. case submitRequest: CreateSubmissionRequest => 

13. / 在 这 里 开始 构建 驱动 程序 (也 就 是 包含 SparkContext 的 应 用 程序 ) 的 

14. // 描述 信息 ,对 应 DriverDescription 实例 

15. // 并 向 Master 的 RPC 终端 masterEndpoint 发 送 请 求 消息 RequestSubmitDriver 
16. val driverDescription = buildDriverDescription( submitRequest) 

a val response = masterEndpoint ask WithRetry[ DeployMessages. SubmitDriverResponse | ( 
18. DeployMessages. RequestSubmitDriver( driverDescription ) ) 

19. val submitResponse = new CreateSubmissionResponse 

20. 

21000 

22000 


3) 构建 DriverDescription 的 buildDriverDescription 方法 的 代码 如 下 。 


1. DriverDescription private def buildDriverDescription( request: CreateSubmissionRequest) :DriverDe- 


scription = | 


// 构建 Command 实例 ,将 主 类 mainClass 封装 到 DriverWrapper( 可 以 通过 jps 查看 ) 


val command = new Command( 





SA 


"org. apache. spark. deploy. worker. DriverWrapper" ， 








6. 


9 

10. 
11. 
站 六 
13. 


内 核 机 制 解析 及 性 能 调 优 





Seq(" | 1 WORKER_URL }","|{{USER_JAR}}",mainClass) ++ appArgs,// args to the 
DriverWrapper 


environmentVariables ,extraClassPath ,extraLibraryPath ,javaOpts ) 








// 构 建 驱动 程序 的 描述 信息 DriverDescription 
new DriverDescription( 


appResource ,actualDriverMemory , actual DriverCores ,actualSuperviseDriver ,command ) 


| 


4) Master 接收 并 处 理 消 息 的 代码 如 下 。 


Se A Ad 


DD IDIPDRPD 忆 天 r 送 庆 王 -r 王 产 r 王 王 一 
人 人 人 二 和 


override def receiveAndReply( context: RpcCallContext) :PartialFunction[ Any,Unit] = | 





// 接收 并 处理 RequestSubmitDriver 消息 
case RequestSubmitDriver( description) => | 
if( state!= RecoveryState. ALIVE ) | 
val msg =s "$| Utils. BACKUP_STANDALONE_MASTER_PREFIX| .$state. "+ 
"Can only accept driver submissions in ALIVE state. " 
context. reply( SubmitDriverResponse( self ,false, None, msg ) ) 
| else | 
// 这 里 的 mainClass 就 是 被 封装 的 应 用 程序 的 主 类 


logInfo(" Driver submitted " + description. command. mainClass ) 























// 创建 Driver 信息 ,在 Master 中 需要 调度 Application 和 Driver 
val driver = createDriver( description ) 

persistenceEngine. addDriver( driver) 

waitingDrivers += driver 


drivers. add ( driver) 


// 开始 根据 调度 机 制 进行 调度 
schedule( ) 


| 


5) Master 的 schedule( ) :调度 机 制 的 调度 代码 如 下 。 


SN 罗 


/沙沙 
* Schedule the currently available resources among waiting apps. This method will be called 
* every time a new app joins or resource availability changes 
2 

private def schedule( ) :Unit = | 
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if( state!= RecoveryState. ALIVE ) | return | 
// Drivers 优先 于 executors 调度 ,人 逻辑 上 需要 先 调 度 驱 动 程序 ,然后 再 为 驱动 程序 的 
// 具体 任务 执行 分 配 Executors 
// Drivers take strict precedence over executors OO 
// 均衡 调度 的 一 种 机 制 
val shuffledWorkers = Random. shuffle( workers)// Randomization helps balance drivers 
for( worker <— shuffled Workers if worker. state == WorkerState. ALIVE ) | 


for( driver <— waitingDrivers ) | 




















if( worker. memoryFree >= driver. desc. mem && worker. coresFree >= driver. desc. cores ) | 
// 开始 启动 Driver ,在 该 方法 中 会 向 Worker 发 送 启 动 Driver 的 请 求 消息 ， 
// 详细 的 消息 发 送 代码 请 参考 源 代码 


launchDriver( worker ,driver) 





waitingDrivers —= driver 


| 


startExecutorsOnWorkers( ) 


6) Worker 上 的 Driver 启动 的 代码 如 下 。 


AN 


和 
os 国人 < 


override def receive:PartialFunction[ Any, Unit | = synchronized | 


case LaunchDriver( driverld , driverDesc) => | 
logInfo( s" Asked to launch driver$ driverld" ) 
// 构造 DriverRunner 实例 
val driver = new DriverRunner( 
conf ， 
driverId ， 
workDir， 
sparkHome, 
// 驱动 的 描述 信息 :DriverDescription 
driverDesc. copy ( command = Worker. maybeUpdateSSLSettings ( driverDesc. command ， 





conf) ) ， 
self, 
workerUri, 
security Mgr) 


drivers( driverld ) = driver 


// 启 动 驱动 程序 


driver. start( ) 
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2 coresUsed += driverDesc. cores 
D2 memoryUsed += driverDesc. mem 
2 } 

24. | 


(2) 提交 方式 为 传统 方式 

这 里 的 传统 方式 指 的 是 在 REST 方式 之 前 ，Spark 所 提供 的 提交 方式 。 此 时 会 将 应 用 程 
序 的 主 类 等 信息 封装 到 org. apache. spark. deploy. Client 类 中 ,该 类 和 REST 方式 下 的 封装 类 
RestSubmissionClient 一 样 ， 也 会 将 提交 的 应 用 程序 封装 到 DriverDescription， 然 后 向 Master 发 
送 RequestSubmitDriver 消息 ， 之 后 的 Master 消息 处 理 与 调度 等 步骤 与 REST 方式 一 样 。 详 细 
的 执行 框架 如 图 3-5 所 示 。 


人 


Client 结 点 
clientEndpoint 
Se 


1.RequestSubmitDriver 
















Worker 结 点 


DriverRunner 


workerEndpoint 








[ 
1 
1 
1 
1 
1 
1 
1 
1 
\ 






2.createDriver 
3.schedule 








O RPC 通 信 终 端 二 与 REST 提 交 方式 的 差异 所 在 
[ 类 的 实例 (包含 进程 启动 的 主 类 ) 











图 3-5 ”传统 提交 方式 下 的 详细 执行 框架 





为 了 体现 各 个 组 件 间 的 部 署 关 系 ， 这 里 以 框架 图 的 形式 进行 描述 ， 相 应 的 ， 可 以 从 时 序 
图 的 角度 去 理解 各 个 类 或 组 件 之 间 的 交互 关系 。 其 中 组 件 Master 、Worker 和 Client 的 标注 在 
方 框 的 左上 角 ， 其 他 方 框 表示 一 个 具体 的 实例 。 其 中 需要 注意 的 是 虚线 方 框 处 是 该 提交 方式 
与 REST 方式 之 间 的 差异 所 在 。 

和 REST 方式 相 比 ， 传 统 的 方式 只 在 向 Master 发 送 提交 应 用 请 求 的 地 方 不 同 ， 其 他 步 又 
都 一 样 。 其 中 ，Client 是 提交 应 用 程序 的 客户 端 处 ， 对 提交 的 应 用 程序 进行 封装 的 类 。 之 后 
各 个 组 件 间 的 交互 流程 分 析 如 下 。 

1) 第 1 步 在 Client 的 和 人口 函数 main 中 ， 在 该 函数 中 会 构建 一 个 与 Master 进行 通信 的 
RpcEndPoint， 即 ClientEndpoint 实例 。 在 ClientEndpoint 实例 构建 后 ， 会 调用 该 实例 的 onStart 
方法 ， 然 后 向 Master 的 通信 端口 发 送 请 求 消息 RedquestSubmitDriver ， 然 后 等 待 反 馈 并 退出 。 

2) Master 接收 到 该 消息 后 ， 执 行 第 2 步 createDriver， 创 建 Driver， 创 建 时 需要 由 Master 
的 调度 机 制 (对 应 第 3 步 schedule) ， 获 取 分 配 的 资源 后 ， 向 Worker (这 些 Worker 启动 时 会 
注册 到 Master 上 ) 的 RPC 终端 发 送 LaunchDriver 消息 。 

3) Worker 在 RPC 终端 接收 到 消息 后 开始 处 理 ， 实 例 化 一 个 DriverRunner， 并 运行 之 前 
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封装 的 应 用 程序 。 
其 中 2)、3) 和 REST 方式 的 处 理 流程 一 样 。 
在 传统 方式 提交 的 执行 框架 中 ， 主 要 的 源 代码 及 其 分 析 如 下 。 























1) Client 的 入 口 函 数 main 的 代码 如 下 。 OO 
1l. /i** 
2 * Executable utility for starting and terminating drivers inside of a standalone cluster. 
3 */ 
4. object Client | 
5, def main( args: Array| String | ) | 
6. 
7. / 构建 RPC 环境 实例 
8. val rpcEnv = 
9. RpckEnv. create ( " driverClient" , Utils. localHostName ( ) ,0, conf, new SecurityManager 
(conf) ) 
10. 
11. // 获取 Master 的 RPC 通信 终端 
I val masterEndpoints = driverArgs. masters. map( RpcAddress. fromSparkURL ) . 
13. map ( rpcEnv. setupEndpointRef ( Master. SYSTEM _ NAME, _, Master. ENDPOINT _ 
NAME)) 





14. // 通过 RPC 环境 实例 构建 客户 端的 RPC 通信 终端 ClientEndpoint 实例 
15. rpcEnv. setupEndpoint ( " client", new ClientEndpoint ( rpcEnv, driverArgs, masterEndpoints, 


conf) ) 

16. 

17. / 等待 Master 反馈 并 退出 

18. rpcEnv. awaitTermination( ) 
19. ' 

20. | 


2) ClientEndpoint 的 onStart 方法 的 代码 如 下 。 


























1. override def onStart( ) :Unit = | 

2 driverArgs. cmd match | 

3. // 这 里 处 理 的 是 启动 应 用 程序 的 消息 

4. case "launch" => 

5.， // 构建 Command 实例 ,将 主 类 mainClass 封装 到 DriverWrapper( 可 以 通过 jps 查看 ) 

6. val mainClass = " org. apache. spark. deploy. worker. DriverWrapper" 

5 

8. val command = new Command( mainClass, 

9. Seq( "||WORKER_URL}}","||USER_JAR}}" ,driverArgs. mainClass) ++ driv- 
erArgs. driverOptions, 

10. sys. env ,classPathEntries, libraryPathEntries ,javaOpts ) 

di 
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// 将 command 封装 到 DriverDescription ,可 以 结合 ApplicationDescription 一 起 查看 


val driverDescription = new DriverDescription ( 


driverArgs. jarUrl ， 
driverArgs. memory, 
driverArgs. cores, 
driverArgs. supervise, 


command ) 


// 发 送 提交 Driver 的 请 求 (注意 ,这 里 的 Driver 可 以 理解 成 请 求 启动 
// 驱动 程序 (Driver Program ) 的 驱动 ) 
ayncSendToMasterAndForwardReply[ SubmitDriverResponse | ( 





RequestSubmitDriver( driverDescription ) ) 


case "kill" => 
val driverld = driverArgs. driverld 
// 发 送 停 止 Driver 的 请 求 
ayncSendToMasterAndForwardReply[ KillDriverResponse | ( RequestKillDriver( driverld ) ) 
| 





Master 的 部 署 习 





Spark 中 的 各 个 组 件 是 通过 脚本 来 局 动 部 署 的 ， 下 面 以 脚本 为 切入 点 开始 分 析 Master 的 


部 署 。 











每 个 组 件 对 应 提供 了 启动 的 脚本 ， 同 时 也 会 提供 停止 的 脚本 。 停 止 脚本 比较 简单 ， 可 以 
自己 查看 ， 在 此 仪 分 析 启 动 脚本 。 

1. Master 部 署 的 启动 脚本 解析 

首先 来 看 下 Master 的 启动 脚本 . /sbin/start - master. sh， 内 容 如 下 。 


Sn A dl pn 


10. 
i 








# 在 脚本 的 执行 结 点 启动 Master 组 件 


# Starts the master on the machine this script is executed on. 


# 如 果 没 有 设置 环境 变量 SPARK_HOME ,会 根据 脚本 所 在 位 置 自动 设置 
证 [ -z"$|SPARK_HOME}" ] ;then 

export SPARK_HOME = "$(cd "dirname "$0" 人 . ;pwd)" 
fi 


# NOTE :This exact class name is matched downstream by SparkSubmit. 


# Any changes need to be reflected there. 
# Master 组 件 对 应 的 类 


12. 
13. 
14. 
15. 
16. 
17. 
18. 
19. 
20. 
21. 
2 
2 
24. 
25. 
26. 
六 
28. 
29. 
30. 
31. 
52， 
33. 
34. 
35. 
36. 
37. 
38. 
39. 
40. 
41. 
42. 
43. 
44. 
45. 
46. 
47. 
48. 
49. 
50. 
51. 
52. 
53. 
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CLASS = " org. apache. spark. deploy. master. Master" 


# 脚 本 的 帮助 信息 

WI va = he 1] Ni = lh iain O) 
echo " Usage:. /sbin/start - master. sh [ options]" 
pattern = " Usage:" 
pattern +=" \ | Using Spark s default log4j profile:" 


pattern +=" \ | Registered signal handlers for" 


# 通过 脚本 spark - class 执行 指定 的 Master 类 ,参数 为 --help 
"$|SPARK_HOME}"/bin/spark — class $CLASS ——help 2>&] |grep ~v "$pattern" 1 > &2 
exit 1 
fi 


ORIGINAL ARGS= "$@" 


# 控 制 启动 Master 时 ,是 否 同时 启动 Tachyon 的 Master 组 件 
START_TACHYON = false 





while(( "$#" ));do 
case$l in 
—— with -tachyon) 
i [!-e"$|SPARK HOME}"/tachyon/bin/tachyon | ;then 
echo " Error: —— with ~ tachyon specified ,but tachyon not found. " 
exit—1 
fi 
START_TACHYON = true 
esac 
shift 


done 
"$|SPARK_ HOME |/sbin/spark - config. sh" 
"$1SPARK_HOME |/bin/load - spark - env. sh" 
# 下 面 的 一 些 参数 对 应 的 默认 配置 属性 
i [ "$SPARK_MASTER_PORT" ="" |;then 
SPARK_MASTER_PORT =7077 


fi 


// 用 于 MasterURL ,所 以 当 没 有 设置 时 ,默认 会 使 用 hostname 而 不 是 IP 地 址 
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54.”// 该 MasterURL 在 Worker 注册 或 应 用 程序 提交 时 使 用 








55. 这 [| "$SPARK_MASTER IP" ="" ] ;then 

56. SPARK _ MASTER _IP = hostname 

Sf 

58. 

59. if [ "$SPARK_ MASTER_ WEBUI_PORT" ="" ] ;then 
60. SPARK_MASTER_WEBUI_PORT = 8080 

‘le 

62. 




















63.”# 通 过 启动 后 台 进 程 的 脚本 spark - daemon. sh 来 启动 Master 组 件 

64. "$|SPARK _ HOME}/sbin"/spark - daemon. sh start$CLASS 1\ 

05. ——ip$SPARK_MASTER_IP -=-port$SPARK_MASTER_PORT -= webui -port$SPARK _ 
MASTER_WEBUI_PORT\ 

66. $ORIGINAL_ARGS 





67. 

68. # 需 要 时 同时 启动 Tachyon ,此 时 Tachyon 是 编译 在 Spark 内 的 

69. 让 [ "$START TACHYON" == "tue" ] ;then 

70. "$1SPARK_HOME "/tachyon/bin/tachyon bootstrap - conf$SPARK_MASTER_IP 
ZL "$|SPARK_HOME}"/tachyon/bin/tachyon format —s 

7 "$1SPARK_HOME "/tachyon/bin/tachyon - start. sh master 

CA 








通过 脚本 的 简单 分 析 ， 可 以 看 出 Master 组 件 是 以 后 台 守 护 进 程 的 方式 启动 的 ， 对 应 后 
护 进 程 的 启动 脚本 spark - daemon. sh， 在 后 台 守 护 进程 的 启动 脚本 spark - daemon. sh 内 
过 脚本 spark - class 来 启动 一 个 指定 主 类 的 JVM 进程 ， 相 关 的 代码 如 下 。 





1l. case "$mode" in 

2. ”# 这 里 对 应 的 是 启动 一 个 Spark 类 

3 (class) 

4 nohup nice —~n "$SPARK_NICENESS" "$|SPARK_HOME}"/bin/spark - class$ com- 
mand "$@" > "$log" 2 >&] </dev/null & 

















SS newpid = "$1" 

6. 68 

7.” # 这 里 对 应 提交 一 个 Spark 应 用 程序 

8. (submit ) 

9. nohup nice —n "$SPARK_NICENESS" "$|SPARK_HOME}"/bin/spark - submit —— 
class $command "$@" > "$log" 2 > &l </dev/null & 

10. newpid = "$1" 

11. 

1 

13. (*) 


14. echo "unknown mode:$modey" 


第 3 章 部 署 模 式 (Deploy) 解析 





Is) exit 1 








通过 脚本 的 分 析 ， 可 以 知道 最 终 执行 的 是 Master 类 (对 应 的 代码 为 前 面 的 CLASS = 
org. apache. spark. deploy. master. Master" ) ， 对 应 的 入 口 点 则 是 Master 伴生 对 象 中 的 main 方 
法 。 下 面 以 该 方法 作为 入 口 点 进一步 解析 Master 部 署 框架 

在 部 署 Master 组 件 时 ， 最 最 简单 的 方式 是 直接 启动 脚本 ， 不 带 任何 选项 参数 ， 命 令 
如 下 。 




















1. ./sbin/start— master. sh 


如 需 设置 选项 参数 ， 可 以 查看 帮助 信息 ， 根 据 自 己 的 需要 进行 设置 。 
2. Master 的 源 代码 解析 
首先 查看 Master 伴生 对 象 中 的 main 方法 ， 代 码 如 下 。 





1 def main( argStrings: Array[ String | ) | 

2 SignalLogger. register( log) 

3 val conf = new SparkConf 

4. // 构建 参数 解析 的 实例 

3 val args = new MasterArguments( argStrings ,conf) 
6 

了 

8 

9 





// 启动 RPC 通信 环境 及 Master 的 RPC 通信 终端 
val (rpcEnv,_,_) =startRpeEnvAndEndpoint( args. host, args. port,args. webUiPort,conf ) 


rpcEnv. awaitTermination( ) 


| 


和 其 他 类 ， 如 SparkSubmit 一 样 ，Master 类 的 入 口 点 处 也 包含 了 对 应 的 参数 类 MasterAr- 
guments。 这 里 简单 介绍 一 下 该 类 ， 包 括 Spark 属性 配置 相关 的 一 些 解析 ， 对 应 在 其 他 地 方 的 
属性 配置 部 分 类 似 。 

下 面 首先 来 看 一 下 MasterArguments 类 的 主要 代码 ， 如 下 所 示 。 











/ 米 米 
x* Master 的 命令 行 解析 器 
* Command - line parser for the master. 
*/ 
private| master | class MasterArguments( args: Array[ String | , conf: SparkConf) | 
// 这 里 和 脚本 中 的 默认 配置 是 一 样 的 
var host = Utils. localHostName( ) 
var port =7077 
var webUiPort = 8080 


var propertiesFile :String = null 

















DE > A er er el cts 
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12. // 这 里 读 取 的 就 是 启动 脚本 中 设置 的 环境 变量 











网 

















13. // Check for settings in environment variables 


14. if( System. getenv(" SPARK_MASTER_HOST" ) 1= null) | 








15. host = System. getenv(" SPARK_MASTER_HOST" ) 

16. } 

A if(System. getenv( "SPARK_MASTER_PORT" ) 1= null) | 

18. port = System. getenv( " SPARK_MASTER_PORT" ). toInt 

19. } 

20. if(System. getenv( "SPARK_MASTER_WEBUI_PORT" ) l= null) | 
ie webUiPort = System. getenv( " SPARK_MASTER_WEBUI_PORT" ). toInt 
2 } 

238 

24. // 命令 行 选项 参数 的 解析 

25. parse( args. toList ) 

26. 





27. // 这 里 会 将 默认 的 属性 配置 设置 到 SparkConf 实例 中 
28. // This mutates the SparkConf,so all accesses to it must be made after this line 


29. propertiesFile = Utils. load DefaultSparkProperties( conf, propertiesF'ile ) 


31. if( conf. contains( " spark. master. ui. port" ) ) | 
3 webUiPort = contf. get( " spark. master. ui. port" ). toInt 


合同 





另外 ，MasterArguments 中 的 printUsageAndExit 方法 ， 对 应 的 就 是 命令 行 中 的 帮助 信息 。 
在 解析 完 Master 的 参数 之 后 ， 调 用 startRpcEnvAndEndpoin 方法 启动 RPC 通信 环境 及 
Master 的 RPC 通信 终端 。 该 方法 的 代码 如 下 。 











/水 水 
* 启动 Master 并 返回 一 个 三 元 组 

* Start the Master and return a three tuple of : 
* (1)The Master RpcEnv 
* (2)The web UI bound port 
* (3)The REST server bound port,if any 
*/ 

def startRpcEnvAndEndpoint( 

host: String, 


A A po 


二 


port : Int ， 


jk 
a 


webUiPort : Int, 
conf:SparkConf) :( RpcEnv, Int, Option[ Int ] ) = | 


中 


20. 
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val securityMgr = new SecurityManager( conf ) 


// 构建 RPC 通信 环境 
val rpcEnv = RpcEnv. create( SYSTEM_NAME, host, port, conf, securityMgr ) O) 


// 构建 RPC 通信 终端 ,这 里 会 实例 化 Master 
val masterEndpoint = rpcEnv. setupEndpoint(ENDPOINT_NAME ， 
new Master( rpcEnv ,rpcEnv. address ,webUiPort ,securityMgr,conf) ) 





// 向 Master 的 通信 终端 发 送 请 求 ,获取 绑 定 的 端口 号 
// 包含 Master 的 web ui 监听 端口 号 和 REST 的 监听 端口 号 
val portsResponse = masterEndpoint askWithRetry[ BoundPortsResponse | ( BoundPortsRequest ) 





(rpcEnv, portsResponse. webUIPort ,portsResponse. restPort ) 


| 


由 第 19 和 第 20 行 代码 可 以 看 到 ， 代 码 中 创建 了 一 个 Master 实例 。 首 先 来 看 一 下 Mater 


的 定义 。 


1 
2 
a 
4. 
5 
6 
7 


private| deploy | class Master( 
override val rpcEnv: RpcEnv, 
address: RpcAddress, 
webUiPort: Int, 
val securityMgr:SecurityManager， 
val conf: SparkConf) 
extends ThreadSafeRpcEndpoint with Logging with LeaderElectable { 


从 第 7 行 代码 可 以 看 到 ，Master 继承 了 ThreadSafeRpcEndpoint 和 LeaderElectable， 其 中 
继承 LeaderElectable 涉及 Master 的 HA ( High Availability ， 高 可 用 性 ) 机 制 ， 这 里 先 关注 
ThreadSafeRpcEndpoint， 继 承 该 类 后 ，Master 作为 一 个 RpcEndpoint， 实 例 化 后 首先 会 调用 
onStart 方法 ， 方 法 的 代码 如 下 所 示 。 


这 


10. 





override def onStart( ) : Unit = | 


logInfo( " Starting Spark master at " +masterUrl ) 


logInfo( s" Running Spark version$ | org. apache. spark. SPARK_VERSION}") 





// 构建 一 个 Master 的 web ui 
// 可 以 查看 向 Master 提交 的 应 用 程序 等 信息 
webUi = new MasterWebUI( this, webUiPort ) 
webUi. bind( ) 
masterWebUiUrl = " http://" +masterPublicAddress + " :" + webUi. boundPort 











// 在 一 个 守护 线程 中 启动 调度 机 制 ,周期 性 地 检查 Worker 是 否 超时 
// 当 Worker 结 点 超时 后 ,会 修改 其 状态 或 从 Master 中 移 除 与 其 相关 的 操作 
checkForWorkerTimeOutTask = forwardMessageThread. scheduleAtFixedRate( new Runnable | 
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14. override def run( ) :Unit = Utils. tryLogNonFatalError | 

15. self send( CheckForWorkerTimeOut) 

16. | 

17. | ,0, WORKER_TIMEOUT_MS, TimeUnit. MILLISECONDS) 

18. 

19. // 默认 情况 下 会 启动 Rest 服务 ,可 以 通过 该 服务 向 Master 提交 各 种 请 求 
20. if( restServerEnabled ) | 

2 val port = conf. getInt( " spark. master. rest. port" ,6066) 

2 restServer = Some( new StandaloneRestServer( address. host ,port,conf,self,masterUrl) ) 
283 } 

24. restServerBoundPort = restServer. map( _. start( ) ) 

29: 


26. // 度量 ( Metroics) 相 关 的 操作 ,用 于 监控 


27. masterMetricsSystem. registerSource( masterSource ) 


28. masterMetricsSystem. start( ) 
2 applicationMetricsSystem. start( ) 
30. // Attach the master and app metrics servlet handler to the web ui after the metrics 


systems are 


31. // started. 

32. masterMetricsSystem. getServletHandlers. foreach( webUi. attachHandler) 

33. application MetricsSystem. getServletHandlers. foreach( webUi. attachHandler) 
34. 

3 // 下 面 是 Master HA 相关 的 操作 

36. val serializer = new JavaSerializer( conf) 

3 大 val( persistenceEngine_,leaderElectionAgent_ ) = RECOVERY _ MODE match | 
38. 

39. } 

40. persistenceEngine = persistenceEngine_ 

41. leaderFlectionAgent = leaderElectionAgent_ 

42. } 








在 启动 Master 组 件 后 ,会 读 取 Master 相关 的 一 些 配置 信息 ， 这 些 信息 可 以 直接 在 
Master 源 代 码 中 查看 。 需 要 注意 的 是 ， 由 于 这 些 配置 信息 是 在 Master 中 使 用 的 ， 因 此 需要 
在 启动 Master 组 件 之 前 进行 配置 ， 保 证 Master 实例 可 以 读 取 正确 的 配置 属性 ; 如 果 在 启 
动 之 后 修改 了 这 些 配 置 属性 ， 则 需要 重新 启动 Master 组 件 (对 应 其 他 组 件 的 相关 配置 的 
修改 与 此 类 似 ) 。 

Master 组 件 与 YARN 或 Mesos 类 似 ， 其 主要 功能 是 资源 管理 与 调度 ， 因 此 会 维护 一 组 提 
供 资源 的 Worker 信息 和 需要 调度 的 应 用 程序 信息 ， 在 Master 组 件 中 会 根据 一 定 的 调度 策略 
为 这 些 应 用 程序 分 配 资源 注册 上 来 的 Worker 中 的 资源 (当前 包含 CPU 与 内 存 ) 。 

下 面 是 维护 这 些 信息 的 变量 定义 ,为 了 方便 分 析 ， 下 面 会 做 些 简单 的 顺序 调整 ， 代 码 
如 下 。 
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// 维 护 Worker 结 点 信息 及 相关 的 映射 信息 
val workers = new HashSet[ WorkerInfo | 
private val i dToWorker = new HashMap| String, WorkerInfo | 
private val addressToWorker = new HashMap|[ RpcAddress, WorkerInfo | O) 





// 维护 全 部 的 ApplicationInfo, 以 及 等 待 、 完 成 的 ApplicationInfo 信息 
val apps = new HashSet[ ApplicationInfo | 





val waitingApps = new ArrayBuffer| ApplicationInfo | 
private val completedApps = new ArrayBuffer| ApplicationInfo | 


private var nextAppNumber =0 


// 维护 ApplicationInfo 的 各 种 映射 信息 

val idToApp = new HashMapl String, ApplicationInfo | 
private val endpointToApp = new HashMap[ RpcEndpointRef, ApplicationInfo | 

private val addressToApp = new HashMap[ RpcAddress, ApplicationInfo | 

// Using ConcurrentHashMap so that master — rebuild ~ ui ~ thread can add a UI after asyncRe- 
buildUI 

private val appIdToUI = new ConcurrentHashMap[ String, SparkUI | 





// 维护 全 部 的 DriverInfo ,以 及 等 待 .完成 的 DriverInfo 信息 


private val drivers = new HashSet[ DriverInfo | 





private val completedDrivers = new ArrayBuffer| DriverInfo | 
// Drivers currently spooled for scheduling 
private val waitingDrivers = new ArrayBuffer[ DriverInfo | 


private var nextDriverNumber =0 





继承 ThreadSafeRpcEndpoint 类 之 后 ， 作 为 RPC 的 一 个 通信 终端 ，Master 会 响应 各 种 消 
息 并 处 理 ， 在 此 过 程 中 会 更 新 Master 中 维护 的 信息 ， 另 外 ， 响 应 资源 请 求 时 进行 资源 调度 
的 过 程 中 也 会 更 新 这 些 信 息 。 这 里 先 来 分 析 Master 对 资源 的 调度 过 程 。 调 度 过 程 在 schedule 
方法 中 ， 有 具体 代码 如 下 。 


Me ry rds 


三 





7 
* 为 等 待 应 用 调度 当前 可 用 的 资源 
* 当 有 新 的 应 用 加 入 或 可 用 资源 发 生变 更 时 调用 该 方法 


* Schedule the currently available resources among waiting apps. This method will be called 









































* every time a new app joins or resource availability changes. 
*/ 
private def schedule( ) :Unit = | 
if(state1= RecoveryState. ALIVE ) | return | 
// Drivers 在 Executors 的 分 配 上 具有 优先 权 





// 对 当前 可 分 配 的 Worker 进行 洗 牌 ,可 以 帮助 Drivers 的 均衡 部 署 









在 为 等 待 
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val shuffledWorkers = Random. shuffle( workers)// Randomization helps balance drivers 
for( worker <— shuffledWorkers if worker state == WorkerState. ALIVE ) | 


// 对 等 待 队列 中 的 Drivers 进行 调度 
for( driver <— waitingDrivers ) | 
只 要 当前 的 Worker 满足 Driver 申请 的 资源 ,包括 内 存 大 小 和 可 用 内 核 数 ， 
// 就 会 在 该 Worker 上 启动 Driver, 并 将 该 Driver 从 等 待 队列 中 移 除 
// 说 明 :Driver 是 驱动 程序 ,在 一 个 结 点 上 启动 ， 
// 和 Application 在 多 个 结 点 上 分 布 式 启动 不 同 ,因此 调度 控制 比较 简单 


if( worker. memoryFree >= driver. desc. mem && worker. coresFree >= driver. desc. cores ) | 
































launchDriver( worker , driver) 


waitingDrivers —= driver 


| 
/7 开始 为 应 用 程序 调度 资源 
startExecutorsOn Workers( ) 


| 





中 的 Driver 分 配 好 资源 之 后 ， 开 始 为 用 户 提交 的 应 用 程序 调度 和 分 配 资 源 ， 具 


体 的 代码 在 startExecutorsOnWorkers 方法 证 ， 代 码 如 下 。 


/ 米 米 
* 调度 并 启动 Workers 上 的 Executors 
* Schedule and launch executors on workers 
*/ 
private def startExecutorsOnWorkers( ) :Unit = | 
// 目前 仅 支 持 简 单 的 FIFO 调度 器 。 首 先 满足 等 待 队列 中 的 第 一 个 应 用 程序 
// 然后 满足 第 二 个 ,依次 调度 
// 在 Spark 框架 中 ,调度 可 以 分 为 多 个 层次 ,包含 应 用 程序 层 首 
// 作 业 (Job) 层 面 的 ,作业 内 的 Stage 层面 ,以 及 一 个 Stage 中 的 
// 任务 集 (TaskSet) 层面 的 调度 
// 在 Master 组 件 中 的 调度 ,可 以 认为 是 面向 应 用 程序 
// (包含 Driver 与 Application ) 层面 的 
// 各 个 层面 上 的 调度 策略 可 以 参考 本 书 的 调度 章节 
// Right now this is a very simple FIFO scheduler. We keep trying to fit in the first app 

















的 
























































// in the queue ,then the second app ,etc. 
for( app <— waitingApps if app. coresLeft >0) | 
val coresPerExecutor: Option| Int | = app. desc. coresPerExecutor 
// 过 滤 Workers ,提取 出 具有 足够 资源 启动 一 个 Executor 的 Workers 
// 提取 之 后 再 根据 可 用 内 核 数 进行 倒序 ,优先 使 用 资源 丰富 的 Worker 结 点 
// 提取 的 条 件 包含 内 存 大 小 和 内 核 数 两 部 分 ,具体 如 下 。 
// 内 存 大 小 的 条 件 
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22. // Worker 的 可 用 内 存 大 于 应 用 申请 的 每 个 Executor 所 需 的 内 存 








23. // 内 核 数 的 条 件 , 有 以 下 两 种 情况 。 
24. // 1) 如果 应 用 申请 了 每 个 Executor 所 需 的 内 核 数 
25. // 则 Worker 的 可 用 内 核 数 必须 大 于 该 内 核 数 OO 


26. ”// 2) 如 果 应 用 对 每 个 Executor 上 的 内 核 数 没有 要 求 
27. // 则 Worker 上 只 需 至 少 有 可 用 的 内 核 即 可 














28. // Filter out workers that dou t have enough resources to launch an executor 

29. val usableWorkers = workers. toArray. filter( _. state == WorkerState. ALIVE) 

30. . filter( worker => worker. memoryFree >= app. desc. memoryPerExecutorMB && 
31. worker. coresFree > = coresPerExecutor. getOrElse(1) ) 

3 . sortBy( _. coresFree). reverse 

33% // 在 提取 的 可 用 Workers 上 为 Executors 指定 分 配 到 的 内 核 数 

34. val assignedCores = scheduleExecutorsOn Workers( app ,usableWorkers, spreadOutApps) 
35. 

36. // 在 指定 了 每 个 Worker 分 配 的 内 核 数 之 后 ,开始 分 配 并 启动 Executor 

3 // Now that we ve decided how many cores to allocate on each worker,let s allocate them 
38. for( pos <—0 until usableWorkers. length it assignedCores( pos) >0)| 

39. allocate WorkerResourceToExecutors( 

40. app , assignedCores( pos ) ,coresPerExecutor, usableWorkers( pos) ) 

41. } 

42. | 

do 


从 代码 可 知 ，startExecutorsOnWorkers 方法 包含 下 列 3 个 步骤 。 

1) 提取 满足 资源 条 件 的 Worker 队列 。 

2) 指定 在 每 个 可 用 Worker 上 分 配 的 内 核 数 。 

3) 根据 在 每 个 可 用 Worker 上 分 配 到 的 内 核 数 ， 在 各 个 Worker 上 调度 和 启动 Executors。 

指定 在 每 个 可 用 Worker 上 分 配 的 内 核 数 在 scheduleExecutorsOnWorkers 方法 中 实现 ， 具 
体 代 码 如 下 。 





/** 
x* 调度 在 Workers 上 启动 的 Executors。 返 回 元 素 为 在 每 个 Worker 上 分 配 的 
* 内 核 个 数 的 数组 


* Schedule executors to be launched on the workers 


米 
* 启动 Executors 有 两 种 模式 : 
* 第 一 种 是 将 应 用 程序 的 Executors 部 署 到 尽 可 能 多 的 Workers 上 
* 这 种 模式 通常 是 为 了 更 好 地 实现 数据 本 地 性 。 默 认 使 用 的 是 第 一 种 模式 
10. * 第 二 种 和 第 一 种 相反 。 部 署 到 尽 可 能 少 的 Worker 上 这 种 模式 通常 用 于 计算 密集 型 
的 应 用 


ll.  * There are two modes of launching executors. The first attempts to spread out an 


1 
之 
3 
4 
Sh * Returns an array containing number of cores assigned to each worker 
6 
多 
8 
9 




















es 














[2 * application s executors on as many workers as possible ,while the second does the 
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13. * opposite(i. e. launch them on as few workers as possible). The former is usually better 
14. * for data locality purposes and is the default. 
15. 洲 


16. * 每 个 Executor 上 的 内 核 数 是 可 配置 的 。 当 显 式 配 置 时 ,如 果 一 个 Worker 上 拥有 
17. ”* 足够 的 内 存 大 小 和 内 核 数 ,同一 个 应 用 程序 就 可 以 在 该 Worker 结 点 上 部 署 








18. * 多 个 Executors。 否 则 ,默认 情况 下 每 个 Executor 会 使 用 Worker 结 点 上 的 全 部 可 用 
19. * 内 核 ,此 时 这 个 Worker 结 点 上 就 不 能 再 启动 男 一 个 Executor 了 

20. 

2 

22: 

23: 

24. 

25. 人 

26. */ 

2 private def scheduleExecutorsOnW orkers( 

28. app : ApplicationInfo, 

29. usableWorkers: Array| WorkerInfo | ， 

30. 

31. /7 控制 启动 Executors 有 两 种 模式 的 变量 

3 spreadOutApps: Boolean) :Array| Int] = | 

33. val coresPerExecutor = app. desc. coresPerExecutor 

34. val minCoresPerExecutor = coresPerExecutor. getOrElse( 1) 

3 

36. // 如 果 没 有 指定 每 个 Executor 分 配 的 内 核 数 , 则 一 个 Worker 上 只 启动 一 个 Executor 
37. val oneExecutorPerWorker = coresPerExecutor. isEmpty 

38. val memoryPerExecutor = app. desc. memoryPerExecutorMB 

39. val numUsable = usableWorkers. length 

40. 

41.”// 元 素 为 在 每 个 Worker 结 点 上 分 配 到 的 内 核 个 数 的 数组 

42. val assignedCores = new Array[ Int | (numUsable)// Number of cores to give to each worker 
43. val assignedExecutors = new Array | Int | ( numUsable )// Number of new executors on 


each worker 


44. // 当前 需要 分 配 的 内 核 个 数 ,应 用 程序 需 分 配 的 剩余 内 核 个 数 或 


45. // 当前 Workers 上 全 部 能 分 配 的 内 核 个 数 ， 

46. // 取 最 小 值 , 避 免 超 过 当前 可 分 配 的 总 内 核 数 

47. var coresToAssign = math. min( app. coresLeft ,usableWorkers. map( _. coresFree). sum) 
48. 

















49. /A/#* 判断 指定 索引 位 置 的 Worker 结 点 是 否 能 为 该 应 用 程序 启动 一 个 Executor */ 
50. 

Sw def canLaunchExecutor( pos:Int) :Boolean = | 

52. / 判断 当前 需要 分 配 的 内 核 数 是 否 满足 每 个 Executor 所 需 的 内 核 数 


53. val keepScheduling = coresToAssign >= minCoresPerExecutor 














54. 
SE 
56. 
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// 判断 当前 Worker 可 用 内 核 数 减 去 当前 结 点 已 经 分 配 的 内 核 数 
// 是 否 满 足 每 个 Executor 所 需 的 内 核 数 


val enoughCores = usableWorkers ( pos ) . coresFree — assignedCores( pos) > = minCore- 


sPerExecutor O) 


// 如 果 人 允许 每 个 Worker 结 点 启动 多 个 Executors ,会 相应 地 启动 一 个 新 的 Executors 
// 否则 ,如 果 该 Worker 结 点 上 已 经 启动 过 一 个 Executor， 
// 只 需要 将 更 多 的 内 核 分 配给 该 Executor 即 可 

















val launchingNewExecutor = !oneExecutorPerWorker || assignedExecutors( pos) ==0 
if(launchingNewExecutor) | 
// 当 启 动 一 个 新 的 Executor 时 ,除了 内 核 数 要 满足 条 件 外 ， 
// 还 需要 判断 新 的 Executor 所 需 的 内 存 是 否 也 满足 条 件 
// 以 及 当前 应 用 程序 的 总 Executor 个 数 是 否 满足 条 件 


val assignedMemory = assignedExecutors( pos) * memoryPerExecutor 





val enoughMemory = usableWorkers ( pos ). memoryFree — assignedMemory >= memory- 
PerExecutor 
val underLimit = assignedExecutors. sum + app. executors. size < app. executorLimit 
keepScheduling && enoughCores && enoughMemory && underLimit 
| else | 
// We re adding cores to an existing executor,so no need 
// to check memory and executor limits 


keepScheduling && enoughCores 


// Keep launching executors until no more workers can accommodate any 
// more executors ,or if we have reached this applicatiou s limits 
// 根据 canLaunchExecutor 条 件 过 滤 可 用 的 Worker 结 点 
var freeWorkers = (0 until numUsable). filter( canLaunchExecutor) 
while( freeWorkers. nonEmpty ) | 
freeWorkers. foreach | pos => 
var keepScheduling = true 
while( keepScheduling && canLaunchExecutor( pos) ) | 
coresToAssign -= minCoresPerExecutor 


assignedCores( pos) += minCoresPerExecutor 


// lf we are launching one executor per worker, then every iteration assigns 1 core 
// to the executor. Otherwise,every iteration assigns cores to a new executor. 
if( oneExecutorPerWorker) | 


assignedExecutors( pos) =1 









99. 


100. 
101. 
102. 
103. 
104. 
105. 
106. 
107. 
108. 
109. 
110. 
111. 
112. 
113. 
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| else | 


assignedExecutors( pos) += 1 





// spreadOutApps 是 指定 启动 的 模式 的 配置 属性 ,根据 该 属性 判断 是 否 在 
// 当前 Worker 上 继续 分 配 内 核 数 ,如 果 spreadOutApps 为 true 的 话 ， 
// 不 再 从 当前 Worker 结 点 上 继续 分 配 ,而 是 从 下 一 个 Worker 结 点 上 继续 分 配 


// Spreading out an application means spreading out its executors across as 





// many workers as possible. If we are not spreading out, then we should keep 
// scheduling executors on this worker until we use all of its resources. 
// Otherwise, just move on to the next worker. 
if( spreadOutApps) | 
keepScheduling = false 


| 


freeWorkers = freeWorkers. filter( canLaunchExecutor) 


| 


assignedCores 


| 


根据 在 每 个 可 用 Worker 上 分 配 到 的 内 核 数 ， 在 各 个 Worker 调度 和 启动 Executors， 代 码 
如 下 。 


Do A A re 


一 5 一 一 
A A roe eM 


人 /沙洲 
* 将 一 个 Worker 结 点 上 的 资源 分 配给 一 个 或 多 个 Executors 
* Allocate a worker s resources to one or more executors. 
* @ param app the info of the application which the executors belong to 
* @ param assignedCores number of cores on this worker for this application 
* @ param coresPerExecutor number of cores per executor 
* @ param worker the worker info 
*/ 
private def allocateWorkerResourceToExecutors( 
app:ApplicationInfo ， 
assignedCores : Int ， 
coresPerExecutor: Option[ Int] ， 
worker: WorkerInfo) :Unit = | 
// 如 果 指 定 了 每 个 Executor 上 的 内 核 个 数 , 就 将 该 Worker 结 点 上 分 配 到 的 内 核 
// 分 给 每 个 Executor; 如 果 没 有 指定 , 则 将 全 部 分 配 到 的 内 核 分 给 一 个 Executor 
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18. 

19. // 该 Worker 结 点 上 需要 启动 的 Executor 个 数 

20. val numExecutors = coresPerExecutor map | assignedCores / _ |. getOrElse(1) 
2 // 每 个 Executor 分 配 到 的 内 核 数 O) 
2 val coresToAssign = coresPerExecutor. getOrElse( assignedCores ) 

23. /为 应 用 程序 添加 Executor ,并 启动 Executor 

24. for (i<—1 to numExecutors) | 

2 val exec = app. addExecutor( worker, coresToAssign ) 

26. launchExecutor( worker ,exec ) 

2 app. state = ApplicationState. RUNNING 

28. | 

29. | 


为 了 更 形象 地 描述 Master 的 调度 机 制 ， 下 面 通过 图 3-6 来 介绍 抽象 的 资源 调度 框架 。 








根据 需求 筛选 : 内核 数 + 内 存 大 小 Executor 
排序 : 根据 可 用 内 核 数 ， 从 大 到 小 


一 1.spreadOutApps=true A 2.spreadOutApps=false 一 一 


| Pe a i Se ee a A 和 re 人 | 
守重 
国 业 M 
me 


2. 依 次 全 占 策略 








1 
1 
1 
1 
1 
可 













1. 轮 流 均 摊 的 策略 





Application Application 








图 3-6 Master 中 抽象 的 资源 调度 框架 











其 中 ，Workerl 到 WorkerN 是 集群 中 全 部 的 Workers 结 点 ， 调 度 时 会 根据 应 用 程序 请 求 
的 资源 信息 ， 从 全 部 Workers 结 点 中 过 滤 ! 1 资源 足够 的 结 点 ， 假设 可 以 得 到 Workerl 到 
WorkerM 的 结 点 。 当 前 过 滤 的 需求 是 内 核 数 和 内 存 大 小 足够 启动 一 个 Executor， 这 是 因为 
Executor 是 集群 执行 应 用 程序 的 单位 组 件 (注意 : Executor 和 任务 (Task) 不 是 同一 个 概 
念 ， 对 应 的 任务 是 在 Executor 中 执行 的 。) 

选 出 可 用 Worker 后 ， 会 根据 内 核 大 小 进行 排序 ， 这 可 以 理解 成 是 一 种 基于 可 用 内 核 排 
序 的 、 简 单 的 负载 均衡 策略 。 然 后 根据 设置 的 spreadOutApps 参数 ， 对 应 指定 两 种 资源 分 配 
策略 。 

1) 当 spreadOutApps = true: 使 用 轮流 均 摊 的 策略 ， 也 就 是 采用 圆桌 (Round - Robin ) 
算法 ,图 3-6 中 的 虚线 表示 第 一 次 轮流 摊派 的 资源 不 足以 满足 申请 的 需求 ， 因 此 开始 第 二 
轮 摊 派 ， 依 次 轮流 均 挫 直到 符合 资源 需求 。 
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2) 当 spreadOutApps = false: 使 用 依次 全 占 策略 ， 依 次 从 可 用 Workers 上 获取 该 Worker 
上 可 用 的 全 部 资源 ， 直 到 符合 资源 需求 。 

对 应 的 图 3-6 中 Worker 内 部 的 小 方块 ， 在 此 表示 分 配 的 资源 的 抽象 单位 ， 对 应 资源 的 
条 件 ， 理 解 的 关键 点 在 于 资源 是 分 配给 Executor 的 ， 因 此 最 终 启动 Executor 时 ， 所 占用 的 资 








源 必须 满足 启动 所 需 的 条 件 。 

前 面 描 述 了 Workers 上 的 资源 如 何 分 配给 应 用 程序 ， 之 后 就 是 正式 开始 为 Executor 分 配 
资源 、 并 向 Worker 发 送 启动 Executor 的 命令 了 。 根 据 申请 时 是 否 明确 指定 需要 为 每 个 Exec- 
utor 分 配 确 定 的 内 核 个 数 ， 有 下 列 两 种 情况 。 

1) 明确 指定 每 个 Executor 需要 分 配 的 内 核 个 数 时 : 每 次 分 配 的 是 一 个 Executor 所 需 的 
内 核 数 和 内 存 数 ， 对 应 在 某 个 Worker 分 配 到 的 总 的 内 核 数 可 能 是 Executor 的 内 核 数 的 倍数 ， 
此 时 ， 该 Worker 结 点 上 会 启动 多 个 Executor， 每 个 Executor 需要 指定 的 内 核 数 和 内 存 数 ( 注 
意 该 Worker 结 点 上 分 配 到 的 总 的 内 存 大 小 ) 。 

2) 未 明确 指定 每 个 Executor 需要 分 配 的 内 核 个 数 时 : 每 次 分 配 1 个 内 核 ， 最 后 所 有 在 
某 Worker 结 点 上 分 配 到 的 内 核 都 会 放 到 一 个 Executor 内 (未 明确 指定 内 核 个 数 ， 因 此 可 以 
一 起 放 入 一 个 Executor) 。 因 此 ， 最 终 该 应 用 程序 在 一 个 Worker 上 只 有 一 个 Executor (这 里 
指 的 是 针对 一 个 应 用 程序 ， 当 该 Worker 结 点 上 存在 多 个 应 用 程序 时 ， 仍 然 会 为 每 个 应 用 程 
序 分 别 启动 相应 的 Executor。 ) 。 

在 此 强调 并 补充 一 下 调度 机 制 中 使 用 的 两 个 重要 的 配置 属性 。 

1) 内 核 个 数 的 控制 属性 在 类 SparkSubmitArguments 的 方法 printUsageAndExit 中 ， 如 下 
所 示 。 








// 指 定 为 所 有 Executors 分 配 的 总 内 核 个 数 
| Spark standalone and Mesos only: 


| ——total - executor - cores NUM Total cores for all executors. 


// 指 定 需 要 为 每 个 Executor 分 配 的 内 核 个 数 
11 Spark standalone and YARN only: 


| ——-executor—cores NUM Number of cores per executor. (Default:1 in YARN mode, 


nl Ar Rs 


| or all available cores on the worker in standalone mode ) 


2) 资源 分 配 策略 : 数据 本 地 性 (数据 密集 ) 与 计算 密集 的 控制 属性 ， 对 应 的 配置 属性 
在 Master 类 中 ， 代 码 如 下 。 


1. private valspreadOutApps = conf. getBoolean( "spark. deploy. spreadOut" , true) 


区 > Worker 的 部 署 | 


Spark 中 的 各 个 组 件 是 通过 脚本 来 启动 部 署 的 ， 为 了 解密 Worker 的 部 署 ， 以 启动 Worker 
的 脚本 为 切入 点 开始 分 析 。 
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部 署 Worker 组 件 时 ， 最 简单 的 方式 是 通过 配置 Spark 部 署 目录 下 的 conf/slaves 文件 ， 然 
后 以 批量 的 方式 来 启动 集群 中 在 该 文件 中 列 出 的 全 部 结 点 上 的 Worker 实例 。 启 动 组 件 的 命 
令 如 下 。 














. /sbin/start - slaves. sh 
另 一 种 方式 是 动态 地 在 某 个 新 增 结 点 上 (注意; 是 新 增 结 点 ， 如 果 之 前 已 经 部 署 过 的 
话 ， 可 以 参考 后 面 对 启 动 多 个 实例 的 进一步 分 析 ) 启动 一 个 Worker 实例 ， 此 时 可 以 在 该 新 
增 的 结 点 上 执行 如 下 启动 命令 。 

















. /sbin/ start — slave. sh MasterURL 


其 中 ， 参 数 MasterURL 表示 当前 集群 中 Master 的 监听 地 址 ， 启 动 后 Worker 会 通过 该 地 
址 动态 注册 到 Master 组 件 ， 从 而 实现 为 集群 动态 添加 Worker 结 点 的 目的 。 

1. Worker 部 署 脚本 的 解析 

部 署 脚本 根据 单个 结 点 及 多 个 结 点 的 Worker 部 署 ， 对 应 有 两 个 脚本 : start - slave. sh 和 
start - slaves. sh。 其 中 start - slave. sh 负责 在 脚本 执行 结 点 启动 一 个 Worker 组 件 ，start - 
slaves. sh 脚本 则 会 读 取 配 置 的 conf/slaves 文件 ， 逐 个 启动 集群 中 各 个 Slave 结 点 上 的 Worker 
组 件 。 

(1) 首先 分 析 脚 本 start - slaves. sh 

脚本 start - slaves. sh 提供 了 批量 启动 集群 中 各 个 Slave 结 点 上 的 Worker 组 件 的 方法 。 
即 ， 可 以 在 配置 好 Slave 结 点 〈 即 配置 好 conf/slaves 文件 ) 之 后 ， 通 过 该 脚本 一 次 性 全 部 启 
动 集群 中 的 Worker 组 件 。 












































脚本 的 代码 如 下 。 
1 # 根 据 conf/slaves 文件 指定 的 每 个 结 点 上 启动 一 个 Slave 实例 , 即 Worker 组 件 
2% #Starts a slave instance on each machine specified in the conf/slaves file. 
3 
4. if[-z"$|SPARK HOME}" |];then 
3) export SPARK_HOME=" $ (cd "dimame " $ 0"™%/.. ;pwd)" 
6. 下 
也 
8 # 根 据 配置 信息 设置 是 否 需 要 同时 启动 Tachyon 的 Slave 实例 
9 START_TACHYON =false 


11. while (( " $#" ) ) ;do 
12. case $ 1 in 


13. —— with -tachyon) 

14. i | !1-e"$|SPARK HOME!}/sbin"/../tachyon/bin/tachyon | ;then 
15. echo " Error: —— with ~ tachyon specified ,but tachyon not found. " 

16. exit —1 

17. fi 

18. START_TACHYON = true 





© 
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esac 
shift 


done 


." $ |SPARK_HOME}/sbin/spark - config. sh" 
." $ |SPARK_HOME}/bin/load ~ spark - env. sh" 


# Find the port number for the master 

if | "$ SPARK_MASTER_PORT" ="" |;then 
SPARK_MASTER_PORT =7077 

fi 








# 这 里 获取 Master 的 卫 信息 ,需要 注意 的 是 ,如 果 当 前 SPARK_MASTER_IP 环境 变量 
# 没 有 配置 的 话 ,会 通过 hostname 命令 来 获取 ,这 时 候 如 果 不 是 在 Master 组 件 所 在 结 
# 点 启动 本 脚本 的 话 ，Master 的 卫 设置 就 不 一 致 了 ,因此 为 了 避免 此 类 错误 , 建议 在 
#Master 组 件 所 在 的 结 点 上 启动 该 脚本 
让 [ " $ SPARK_MASTER_IP" ="" ] ;then 

SPARK_MASTER_IP = "hostnamey 
fi 




















# 通过 slaves. sh 脚本 启动 Tachyon 的 Slave 实例 
if [ " $ START_TACHYON" =="true" ] ;then 

" $ |SPARK HOME}/sbin/slaves. sh" cd " $ {SPARK_HOME}" \;" $ |SPARK_HOME!/ 
sbin"/.. /tachyon/bin/tachyon bootstrap ~ conf " $ SPARK _ MASTER_IP" 


# set —t so we can call sudo 

SPARK_SSH_OPTS =" ~ o StrictHostKeyChecking = no ~ t" " $ |SPARK_HOME |}/sbin/ 
slaves. sh" cd " $ {SPARK_HOME}" \;" $ {SPARK_ HOME |/tachyon/bin/tachyon — 
start. sh" worker SudoMount \;sleep 1 
fi 

















# 通 过 slaves. sh 脚本 启动 Worker 实例 ,这 里 会 调用 Worker 启动 的 男 一 个 
# 脚 本 start - slave. sh 




















# Launch the slaves 
"$1SPARK_HOME'}/sbin/slaves. sh" cd " $ |SPARK_ HOME}" \;" $ 1SPARK_ HOME 1 7Z 
sbin/start - slave. sh" "spark://$ SPARK MASTER_ IP.: $ SPARK_MASTER_PORT" 


其 中 ， 脚 本 slaves. sh 通过 SSH 协议 在 指定 的 各 个 Slave 结 点 上 执行 各 种 命令 ， 代 人 码 比 较 
简单 ， 建 议 大 家 自行 查看 。 

在 ssh 启动 的 start - slave. sh 命令 中 ， 可 以 看 到 它 的 参数 是 "spark://$ SPARK_MASTER 
_IP:$ SPARK_MASTER_PORT" ， 这 实际 上 就 是 Master URL 的 值 的 拼接 代码 。 
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(2) 继续 分 析 脚 本 start - slave. sh 
从 前 面 start - slaves. sh 脚本 的 分 析 可 以 看 到 ， 最 终 是 在 各 个 Slave 结 点 上 执行 start - 
slave. sh 脚本 来 部 署 Worker 组 件 的 ， 相 应 的 ， 就 可 以 通过 该 脚本 动态 地 为 集群 添加 新 的 
































Worker 组 件 。 > 
脚本 的 代码 如 下 。 
1. 
2 if [zs"$|SPARK HOME}" ];then 
3 export SPARK_HOME=" $ (cd "dimame " $ 0"™%/.. ;pwd)" 
4. ff 
5 
6. #NOTE:This exact class name is matched downstream by SparkSubmit. 
7.  # Any changes need to be reflected there. 
8.”# Worker 组 件 对 应 的 类 
9. CLASS = "org. apache. spark. deploy. worker. Worker" 
10. 
11. # 脚 本 的 用 法 ,其 中 master 参数 是 必 选 的 ,Worker 需要 与 集群 的 Master 通信 
12. # 这 里 的 master 对 应 Master URL 信息 
13. i [[ $#-11]]Il[["$@"=*--help]] ll[["$@"=*—-h |]|];then 
14. echo " Usage:. /sbin/start - slave. sh [options | <master >" 
ls pattern = " Usage:" 
16. pattern +=" \|Using Spark s default log4j profile:" 
17. pattern += " \ | Registered signal handlers for" 
18. 
19. "$ {SPARK HOME}"/bin/spark -class $ CLASS --heljp2>&l | grep ~—v"$ pattern" 1 > &2 
20. exit 1 
lf 
2 
23. ."$ |SPARK_HOME |/sbin/spark - config. sh" 
24. 
25. ."$ |SPARK_HOME}/bin/load - spark ~ env. sh" 
26. 
27. # First argument should be the master; we need to store it aside because we may 
28. # need to insert arguments between it and the other arguments 
29. MASTER= $1 
30. shift 
Si 
32. # Worker 的 web ui 的 端口 号 设置 
33. # Determine desired worker port 
34. i [ "$ SPARK WORKER WEBUI PORT" ="" |;then 
35. SPARK_WORKER_WEBUI_PORT = 8081 
36. 下 








在 手动 启 
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# 在 结 点 上 启动 指定 序号 的 Worker 实例 


# Start up the appropriate number of workers on this machine. 


# quick local function to start a worker 

function start_instance | 

# 指 定 的 Worker 实例 的 序号 ,一 个 结 点 上 可 以 部 署 多 个 Worker 组 件 , 对 应 有 多 个 实例 
WORKER_NUM=$ 1 
shift 


i ["$ SPARK WORKER_PORT" ="" |;then 
PORT_FLAG = 
PORT_NUM = 

else 
PORT_FLAG =" -- port" 


PORT_ NUM = $ (( $ SPARK WORKER_PORT+ $ WORKER_NUM -1 )) 
fi 
WEBUI_PORT= $(( $ SPARK_ WORKER_WEBUI PORT+ $ WORKER_NUM -1 )) 








# 和 Master 组 件 一 样 , Worker 组 件 也 是 使 用 启动 守护 进程 的 spark - daemon. sh 脚本 来 
# 启动 一 个 Worker 实例 的 
" $1SPARK_HOME}/sbin"/spark - daemon. sh start $ CLASS $ WORKER_NUM \ 
——webui— port " $ WEBUI_PORT" $ PORT_FLAG $ PORT_NUM $ MASTER" $@" 





# 一 个 结 点 上 部 署 几 个 Worker 组 件 是 由 SPARK_WORKER_INSTANCES 环境 变量 控制 的 ， 
# 默 认 情 况 下 只 部 署 一 个 实例 ,start_instance 方法 的 第 一 个 参数 为 实例 的 序号 
让 [ " $ SPARK_WORKER_INSTANCES" ="" ] ;then 


start_instance 1 " $@" 











else 
for ((i=0;i< $ SPARK_ WORKER_INSTANCES;i++ ) ) ;do 
start_instance $((1+$1))"$@" 
done 
fi 


动 Worker 实例 时 ， 如 果 需 要 在 一 个 结 点 上 部 署 多 个 Worker 组 件 ， 则 需要 配置 

















SPARK_WORKER_INSTANCES 环境 变量 ， 和 否则 多 次 启动 脚本 部 署 Worker 组 件 时 会 报错 ， 其 
原因 在 于 spark - daemon. sh 脚本 的 执行 控制 ， 这 里 给 出 关键 代码 的 简单 分 析 。 
首先 脚本 中 有 实例 是 否 已 经 运行 的 判断 ， 代 码 如 下 。 


a Er 














run_command( ) | 
mode=" $1" 
shift 
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mkdir ~p " $ SPARK_PID_DIR" 


# 检 查 记录 对 应 实例 的 PID 的 文件 ,如 果 对 应 进程 已 经 运行 , 则 会 报错 
WL i on 人 
TARGET ID =" $ (cat" $ pid")" 
i [[ $(ps—-p"$ TARGET ID" ~o comm=)= ~ "java" ||;then 
echo " $ command running as process $ TARGET_ID. Stop it first. " 
exit 1 
fi 
fi 


其 中 ， 记 录 对 应 实例 的 PID 的 文件 相关 代码 如 下 。 


人 


呈 





# 这 是 PID 文件 所 在 的 目录 ,如 果 没有 设置 ,默认 为 /tmp 
# 如 果 使 用 了 默认 目录 ,可 能 会 出 现 停止 组 件 失败 的 信息 ， 
# 原因 在 于 该 /tmp 下 的 文件 可 能 会 被 系统 自动 删除 
让 [ " $ SPARK_PID_DIR" ="" ] ;ithen 

SPARK_PID_DIR = /tmp 
下 











# 这 是 指定 实例 编号 对 应 的 pid 文件 的 路 径 
# 其 中 $ instance 代表 实例 编号 ,因此 如 果 编 号 相同 的 话 ,对 应 的 是 同一 个 文件 
pid =" $ SPARK_PID_DIR/spark - $ SPARK_IDENT STRINGC -= $ command - $ instance. pid" 



































从 上 面 的 分 析 可 以 看 出 ， 如 果 不 是 通过 设置 SPARK_WORKER_INSTANCES， 然 后 一 次 
性 启动 多 个 Worker 实例 ， 而 是 手动 一 个 个 地 启动 的 话 ， 对 应 的 ， 在 脚本 中 每 次 启动 时 的 实 
例 编号 都 是 1， 在 后 台 守 护 进 程 的 spark - daemon. sh 脚本 中 生成 的 pid 就 是 同一 个 文件 ， 
此 第 二 次 启动 时 ，pid 文件 已 经 存在 ， 此 时 就 会 报错 (对 应 停止 时 也 是 通过 读 取 pid 文件 获 
取 进 程 ID 的 ， 因 此 自动 停止 多 个 实例 的 话 ， 也 需要 设置 SPARK_WORKER_INSTANCES)。 

2. Worker 的 源 代 码 解析 

首先 查看 Worker 伴生 对 象 中 的 main 方法 ， 代码 如 下 。 








1 
之 
3 
4 
Ss 
6 
% 
8 
9 























private| deploy | object Worker extends Logging | 
val SYSTEM_NAME = " spark Worker" 
val ENDPOINT_NAME =" Worker" 


def main( argStrings: Array[ String | ) | 
SignalLogger. register( log) 
val conf = new SparkConf 

// 构 建 解析 参数 的 实例 


val args =new WorkerArguments( argStrings ,conf ) 











10. /启动 RPC 通信 环境 及 Worker 的 RPC 通信 终端 
val rpcEnv = startRpcEnvAndEndpoint( args. host ,args. port ,args. webUiPort ,args. cores ， 


15. } 


可 以 看 到 ， 
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args. memory ,args. masters ,args. workDir ,conf = conf) 


rpcEnv. awaitTermination( ) 


| 








Worker 伴生 对 象 中 的 main 方法 的 格式 和 Master 基本 一 致 。 通 过 参数 的 类 型 








WorkerArguments 来 解析 命令 行 参 数 ， 具 体 的 代码 解析 可 以 参考 Master 结 点 部 署 时 的 Master- 
Arguments 的 代码 解析 。 
另外 ，MasterArguments 中 的 printUsageAndExit 方法 对 应 的 就 是 命令 行 中 的 帮助 信息 。 
在 解析 完 Worker 的 参数 之 后 ， 调 用 startRpcEnvAndEndpoint 方法 启动 RPC 通信 环境 及 
Worker 的 RPC 通信 终端 。 该 方法 的 代码 解析 可 以 参考 Master 结 点 部 署 时 使 用 的 同名 方法 的 





代码 解析 。 





最 终 会 实例 化 一 个 Worker 对 象 。Worker 也 是 继承 ThreadSafeRpcEndpoint， 对 应 的 也 是 























一 个 RPC 的 通信 终端 ， 实 例 化 该 对 象 后 会 调用 onStart 方法 ， 该 方法 的 代码 如 下 。 








override def onStart( ) | 


// 刚 启动 时 Worker 肯定 是 未 注册 的 状态 

assert( |registered ) 

logInfo( " Starting Spark worker % s:%d with %d cores,%s RAM". format( 
host, port , cores , Utils. megabytesToString( memory ) ) ) 

logInfo( s" Running Spark version $ {org. apache. spark. SPARK_VERSION}") 

logInfo( " Spark home:" + sparkHome) 





// 构 建 工 作 目 录 
createWorkDir( ) 


// 启 动 Shuffle 服务 
shuffleService. startIfEnabled( ) 


// 和 Master 的 web ui 一样 ,Worker 也 会 启动 一 个 web ui 
webUi = new WorkerWebUI( this, workDir, webUiPort) 
webUi. bind( ) 





// 注 册 到 Master: Spark 集群 是 Master/ Slaves 结构 ,每 个 Slave 结 点 上 启动 Worker 
// 组 件 时 ,都 需要 癌 集 群 中 的 Master 进行 注册 
registerWithMaster( ) 





metricsSystem. registerSource( workerSource) 
metricsSystem. start( ) 
//Attach the worker metrics servlet handler to the web ui after the metrics system is started. 


metricsSystem. getServletHandlers. foreach ( webUi. attachHandler) 
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其 中 ，createWorkDir( ) 方 法 对 应 构建 了 该 Worker 结 点 上 的 工作 目录 ， 后 续 在 该 结 点 上 
执行 罗 Application 相关 信息 都 会 存放 在 该 目录 下 。 人 代码 如 下 。 


1 private def createWorkDir( ) | 

2 workDir = Option( workDirPath). map( new File( _) ). getOrElse( new File( sparkk Home," work" ) ) O) 
3 try | 

4 //This sporadically fails - not sure why ... lworkDir. exists( ) && !workDir mkdirs( ) 

3 //So attempting to create and then check if directory was created or not. 

0 workDir. mkdirs( ) 

也 

8 | 

和 1 





可 以 看 到 如 果 没 有 设置 workDirPath ， 默 认 使 用 的 是 sparkHome 目录 下 的 work 子 目录 。 
对 应 的 workDirPath 在 Worker 实例 化 时 传人 ， 反 推 代 码 可 以 查 到 该 变量 在 WorkerArguments 
中 设置 。 相 关 代 码 有 两 处 ， 一 处 在 WorkerArguments 的 主 构造 体 中 ， 代 码 如 下 。 





1. if (System. getenv("SPARK WORKER_DIR")!=null)| 
2 workDir = System. getenv( " SPARK_WORKER_DIR" ) 
3 


即 workDirPath 由 环境 变量 "SPARK_WORKER_DIR" 设 置 。 
男 外 一 处 在 命令 行 选项 解析 时 设置 ， 代 码 如 下 。 


1. private def parse(args: List[ String |] ) : Unit = args match | 
久 

3 case (" ——work— dir"|" -d" )::valuel::tail => 

4. workDir = value 

3 parse( tail ) 

GE 

et 


即 workDirPath 由 启动 Worker 实例 时 传人 的 可 选项 " --work -dir" 设 置 。 





[0 属性 配置 : 通常 由 命令 可 选项 来 动态 设置 启动 时 的 配置 属性 ， 此 时 配置 的 优先 级 高 于 默认 的 属性 文件 
及 环境 变量 中 设置 的 属性 。 





启动 Worker 后 的 一 个 关键 步骤 就 是 注册 到 Master， 对 应 的 方法 registerWithMaster( ) 的 代 
人 码 如 下 。 


private def registerWithMaster( ) | 
//onDisconnected may be triggered multiple times ,so don t attempt registration 
//if there are outstanding registration attempts scheduled. 


// 设 置 注 册 重 试 定时 带 


registrationRetryTimer match | 





GA re 


case None => 








续 


2 


查看 tryRegisterAllMasters( ) 方 法 ， 代 码 如 下 。 





二 交 N 


ee i 
er 


一 一 一 一 
SA eb 


16. 
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registered = false 

// 尝 试 注册 到 所 有 的 Masters 

registerMasterF utures = tryRegisterAllMasters( ) 
// 控 制 重 试 的 次 数 
connectionAttemptCount =0 


/构建 注册 重 试 定时 器 ,注意 初始 注册 重 试 定时 器 的 时 间 设 置 

















// 注 册 重 试 定时 器 会 周期 性 地 向 Worker 本 身 发 送 ReregisterWithMaster 消息 
registrationRetryTimer = Some(forwordMessageScheduler. scheduleAtFixedRate( 
new Runnable | 
override def run( ) :Unit = Utils. tryLogNonFatalError | 
Option( self). foreach( _. send( ReregisterWithMaster) ) 
| 
局 
INITIAL_REGISTRATION_RETRY_INTERVAL_SECONDS, 
INITIAL_REGISTRATION_RETRY_INTERVAL_ SECONDS, 
TimeUnit. SECONDS) ) 
case Some(_) => 
logInfo( " Not spawning another attempt to register with the master, since there is an" + 


WD 


attempt scheduled already. " ) 


private def tryRegisterAllMasters( ) :Array[ JFuture[ _] |] =| 
// 对 每 个 Master 都 提交 一 次 注册 请 求 
masterRpcAddresses. map | masterAddress => 
// 通 过 注册 线程 池 提 交 ,注意 线程 池 大 小 的 设置 


registerMasterThreadPool. submit( new Runnable | 





override def run( ) :Unit = | 
try | 
logInfo( " Connecting to master " + masterAddress +"...") 
/获取 Master 的 RPC 通信 终端 
val masterEndpoint = 


IpcEnv. setupEndpointRef( Master SYSTEM_NAME ,masterAddress ,Master ENDPOINT _ 





NAME) 
/向 特定 的 Master 的 RPC 通信 终端 发 送 注册 Worker 的 消息 
registerWithMaster( masterEndpoint ) 




















| catch | 
case ie:InterruptedException => //Cancelled 


case NonFatal(e) => logWarning( s" Failed to connect to master $ masterAddress" ,e) 


| 
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其 中 registerWithMaster (masterEndpoint) 向 特定 Master 的 RPC 通信 终端 发 送 消息 ， 并 是 在 
接收 到 反馈 消息 后 ， 进 一 步调 用 handleRegisterResponse 方法 进行 处 理 。 对 应 的 处 理 代码 如 下 。 















































1. private def handleRegisterResponse( msg: RegisterWorkerResponse) : Unit = synchronized | O) 

2 msg match | 

38 // 成 功 注册 该 Worker 结 点 ,设置 registered ,修改 当前 的 Master 

4. case RegisteredWorker( masterRef, masterWebUiUzl ) => 

SS logInfo( " Successfully registered with master " + masterRef. address. toSparkURL) 

6. registered = true 

k changeMaster( masterRef, masterWebUiUr!) 

8. // 启 动 周期 性 心跳 发 送 调度 器 ,在 Worker 生命 周期 中 定期 向 Worker 自动 发 送 

9. //SendHeartbeat, 在 receive 方法 中 会 向 Master 发 送 心跳 

10. forwordMessageScheduler. scheduleAtFixedRate( new Runnable | 

11. override def run( ) :Unit = Utils. tryLogNonFatalError | 

2 self. send( SendHeartbeat ) 

13. | 

14. 1 ,0, HEARTBEAT_MILLIS, TimeUnit. MILLISECONDS) 

15. /启动 工作 目录 的 定期 清理 调度 需 , 默 认 情 况 下 该 配置 属性 为 false， 

16. // 需 要 手动 设置 ,对 应 的 属性 名 为 " spark. worker cleanup. enabled" 

17. if (CLEANUP_ENABLED) | 

18. logInfo( 

19. s" Worker cleanup enabled ;old application directories will be deleted in: $ workDir" ) 

20. forwordMessageScheduler. scheduleAtFixedRate( new Runnable | 

2 override def run( ) :Unit = Utils. tryLogNonFatalError | 

2 self send( WorkDirCleanup ) 

23. | 

24. |}, CLEANUP _ INTERVAL _ MILLIS, CLEANUP _ INTERVAL _ MILLIS ， 
TimeUnit. MILLISECONDS) 

2 } 

26. 

27. // 注 册 失 败 则 退出 

28. case RegisterWorkerFailed( message) => 

29. if ( Iregistered ) | 

30. logError( " Worker registration failed:" + message) 

31. System. exit( 1) 

3 } 

33. /注册 的 Master 处 于 Standby 状态 

34. case MasterInStandby => 

3 /LTgnore. Master not yet ready. 

36. } 

S78 } 


分 析 到 这 一 步 ， 已 经 明确 了 注册 及 对 注册 的 反馈 信息 的 处 理 细节 ， 下 面 来 进一步 分 析 注 
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册 重 试 定时 器 的 相关 人 处理， 注册 重 试 定时 硕 会 定期 向 Worker 本 身 发 送 ReregisterWithMaster 
消息 ， 因 此 可 以 在 receive 方法 中 查看 该 消息 的 处 理 ， 具 体 代 人 码 如 下 。 


override def receive:PartialFunction[ Any, Unit| = synchronized | 


1 

多 

3 case ReregisterWithMaster => 
4. reregisterWithMaster( ) 
3 

6 


| 


最 终 会 调用 registerWithMaster 方法 。 








3 内 部 交互 的 消息 机 制 ) 


1. 部 署 组 件 之 间 的 交互 消息 

Spark 是 一 个 分 布 式 集群 ， 各 个 组 件 通过 事件 (消息) 啊 应 机 制 进行 协作 。 所 有 与 集群 
部 署 相关 的 消息 都 在 DeployMessages 类 中 定义 。 读 者 可 以 根据 发 送 的 消息 及 其 对 应 反馈 的 消 
息 进行 整理 ， 也 可 以 根据 DeployMessages 类 中 的 定义 形式 进行 归 类 。 

下 面 根 据 DeployMessages 类 中 的 消息 定义 简单 整理 成 表格 的 形式 ， 方 便 读 者 查阅 ， 如 
表 3-10 ~3-22 所 示 。 














表 3-10 Worker 到 Master 的 消息 

















消息 描 述 

Worker 向 Master 发 送 的 注册 消息 。 在 启动 Worker 时 ， 首 先 需要 注册 到 Master， 由 
Master 负责 管理 ， 并 调度 Worker 上 的 资源 

Worker 向 Master 发 送 Executor 状态 变更 的 消息 。Executor 在 Worker 上 执行 ， 当 状态 
发 送 变 化 时 ， 需 要 通知 Master 

Worker 向 Master 发 送 Driver 状态 变更 的 消息 。Driver 在 Worker 上 执行 ， 当 状态 发 送 
变化 时 ， 需 要 通知 Master 
WorkerSchedulerStateResponse 在 收 到 MasterChanged 消息 后 ， 反 馈 Worker 结 点 上 调度 状态 信息 的 消息 定义 

Heartbeat Worker 向 Master 发 送 的 心跳 消息 























RegisterWorker 











ExecutorStateChanged 








DriverStateChanged 



































表 3-11 Master 到 Worker 的 消息 











































































































消息 描述 
Registered Worker Master 向 Worker 发 送 的 注册 成 功 的 消息 
RegisterWorkerFailed Master 向 Worker 发 送 的 注册 失败 的 消息 
MasterInStandby Master 向 Worker 发 送 当前 处 于 Standby 状态 的 消息 
ReconnectWorker Master 在 收 到 Worker 结 点 的 心跳 消息 后 反馈 的 重新 连接 Worker 的 消息 
KillExecutor Master 向 Worker 发 送 的 停止 Executor 的 消息 
LaunchExecutor Master 向 Worker 发 送 的 启动 Executor 的 消息 
LaunchDriver Master 向 Worker 发 送 的 启动 Driver 的 消息 
KillDriver Master 向 Worker 发 送 的 停止 Driver 的 消息 
ApplicationFinished Master 向 Worker 发 送 的 应 用 程序 完成 的 消息 
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表 3-12 Worker 内 部 的 消息 
















































































消 息 描述 
WorkDirCleanup 周期 性 发 送 到 Worker 终端 ， 以 便 清理 应 用 程序 的 消息 
ReregisterWithMaster Worker 尝试 重新 注册 到 Master 的 消息 O) 
表 3-13 AppClient 到 Master 的 消息 
消 息 描述 
RegisterApplication 启动 驱动 程序 之 后 ，AppClient 向 Master 发 送 的 注册 应 用 程序 的 请 求 
UnregisterApplication AppClient 在 收 到 StopAppClient 消息 之 后 ， 向 Master 发 送 的 取消 注册 应 用 程序 的 请 求 
在 Master HA 时 ， 当 Master 开始 恢复 元 数据 信息 时 ， 会 向 AppClient (以 及 当前 注册 














MasterChangeAcknowledged 上 来 的 各 个 Workers 结 点 ) 发 送 Master 变更 的 消息 MasterChanged， 在 收 到 并 处 理 完 该 
消息 时 ，AppClient 向 Master 发 送 确认 的 消息 MasterChangeAcknowledged 
RequestExecutors AppClient 向 Master 发 送 的 期 望 获取 的 总 的 Executor 个 数 的 资源 请 求 
与 RequestExecutors 类 似 ， 向 Master 发 送 Executor 的 k 记 请求。 发 送 这 两 个 消息 的 请 


























KillExecutors 
a 求 的 调度 可 以 跟踪 到 动态 资源 调度 的 客户 端 ExecutorAllocationClient 中 
表 3-14 Master 到 AppClient 的 消息 
消 息 描 。 述 

















Master 收 到 AppClient 的 应 用 程序 的 注册 消息 RegisterApplication 之 后 ， 当 成 功 注册 到 
Master 时 ， 向 AppClient 反馈 的 已 经 注册 的 消息 
当 Master 在 调度 的 Worker 结 点 上 发 送 启 动 Executor 之 后 ， 向 AppClient 发 送 已 经 添加 








RegisteredApplication 










































































ExecutorAdded 
xecutorAdded Executor 的 消息 
在 Master 中 ， 当 收 到 Worker 发 送 来 的 Executor 状态 变更 消息 ExecutorStateChanged , 
或 者 在 某 些 场景 下 移 除了 注册 在 Master 结 点 上 的 Worker 结 点 时 ,会 向 AppClient 发 送 这 
ExecutorUpdated 
些 相 关 的 ExecutorUpdated 信息 (针对 前 面 两 种 ， 分 别 包 含 Worker 上 特定 Executor 变更 
或 全 部 Executor 变更 消息 
当 Master 发 现 应 用 程序 处 理 失败 或 完成 时 ， 会 处 理 内 部 相关 的 数据 信息 ， 同 时 向 
ApplicationRemoved 
AppClient 发 送 该 应 用 程序 已 经 移 除 的 消息 








表 3-15 DriverClient 与 Master 交互 的 消息 



















































































































































































消息 描 述 
ee DriverClient 端 向 Master 发 送 的 Driver 提交 请 求 。 另 外 ， 在 REST 服务 器 收 到 启动 应 用 
程序 时 ， 也 会 向 Master 发 送 该 消息 
SubmitDriverResponse Master 在 收 到 RequestSubmitDriver 消息 后 反馈 的 消息 
当 传 人 以 Cluster 部 署 模式 提交 应 用 时 所 封装 的 Client 的 参数 为 kil 而 非 launch 时 ， 
RequestKillDriver 会 通过 在 Client 对 象 的 RPC 通信 终端 DriverClient 实例 中 向 Master 发 送 Kill 掉 Driver 的 
请 求 。 同 样 在 REST 服务 器 也 会 向 Master 发 送 该 消息 
KillDriverResponse Master 在 收 到 RequestKillDriver 消息 后 反馈 的 消息 
当 Client 对 象 的 RPC 通信 终端 DriverClient 实例 收 到 Master 的 反馈 信息 时 (包含 启动 
RequestDriverStatus (launch) 与 停止 (kill) 消息 ) ， 会 向 Master 发 送 获取 Driver 状态 信息 的 请 求 。 同 样 在 
REST 服务 器 也 会 向 Master 发 送 该 消息 
DriverStatusResponse Master 在 收 到 DriverStatusResponse 消息 后 反馈 的 消息 
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表 3-16 AppClient 内 部 的 消息 




















消息 描 ” 述 
StopAppClient 在 停止 AppClient 时 ， 内 部 向 自己 的 RPC 通信 终端 发 送 的 停止 消息 





表 3-17 Maste 到 Worker 和 AppClient 的 消息 























消息 描述 
在 Master 启动 或 Master HA 中 的 Master 发 生变 更 ， 在 恢复 持久 化 的 元 数据 信息 时 ， 问 
MasterChanged 


对 应 的 Worker 与 AppClient 发 送 的 Master 变更 消息 


表 3-18 MasterWebUI 到 Master 的 消息 


























消 息 描述 
RequestMasterState MasterWebUI 端 向 Master 发 送 的 请 求 查询 Master 状态 信息 的 请 求 


表 3-19 Master 到 MasterWebUI 的 消息 




















消 息 描述 
MasterStateResponse Master 为 MasterWebUI 发 送 的 状态 响应 信息 ， 是 RequestMasterState 请 求 信 息 的 反馈 


表 3-20 ”WorkerWebUI 发 送 到 Worker 的 消息 




















消 息 描述 
RequestWorkerState WorkerWebUI 端 向 Worker 发 送 的 请 求 查询 Worker 状态 信息 的 请 求 


表 3-21 Worker to WorkerWebUI 的 消息 









































消 息 描述 
WorkerStateResponse Worker 为 WorkerWebUI 发 送 的 状态 响应 信息 , 是 RequestWorkerState 请 求 信息 的 反馈 


表 3-22 各 个 地 方 用 于 存活 检查 的 消息 




















消 息 描述 
SendHeartbeat 发 送 心 跳 消 息 





2. 驱动 程序 及 其 相关 的 交互 消息 
除了 分 布 式 集群 中 各 个 组 件 之 间 的 消息 交互 之 外 ,在 用 户 提交 应 用 程序 之 后 ， 会 有 一 部 

















分 与 调度 相关 的 交互 信息 。 这 部 分 信息 可 以 在 CoarseGrainedClusterMessage 类 的 定 义 文 件 中 
找到 ， 读 者 可 以 根据 发 送 的 消息 及 其 对 应 反馈 的 消息 进行 整理 ， 也 可 以 根据 CoarseGrained- 
ClusterMessage 类 中 的 定义 形式 自行 整理 归 类 。 


Master HA 的 部 署 ) 


1.Master HA 部 署 脚本 的 解析 
通过 前 面 对 Master 启动 脚本 的 分 析 ， 可 以 知道 内 部 是 使 用 启动 守护 进程 的 脚本 spark - 
daemon. sh 来 启动 Master 实例 。 脚 本 spark - daemon. sh 启动 时 会 检查 当前 实例 的 pid 是 否 已 
经 存在 ， 因 此 ， 如 果 想 在 单机 上 模拟 出 一 个 Master HA 的 部 署 集群 ， 需 要 手动 修改 Master 实 
例 的 序号 ， 这 样 才能 在 单机 上 同时 启动 多 个 Master 实例 。 
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原 有 启动 Master 实例 的 代码 如 下 。 


1. "S$|SPARK HOME}/sbin"/spark - daemon. sh start $ CLASS 1 、\ 

2. —--ip $ SPARK MASTER_IP -=-port $ SPARK_MASTER_PORT -=- webui -port $ SPARK_ 
MASTER_WEBUI_PORT \ © 

3. $ ORIGINAL ARGS 


其 中 ,第 1 行 传 递 给 脚本 spark - daemon. sh 的 实例 序号 为 1， 如 果 需 要 单机 启动 第 二 个 
Master 实例 来 模拟 Master HA ， 需要 修改 该 序号 1 为 2 : 对 应 的 代码 修改 如 下 。 

















1. "S$|SPARK HOME})/sbin"/spark - daemon. sh start $ CLASS 2\ 

2. —--ip $ SPARK MASTER_IP -=-port $ SPARK_MASTER_PORT -=- webui-port $ SPARK_ 
MASTER_WEBUI_PORT \ 

3. $ ORIGINAL ARGS 


此 时 再 次 使 用 脚本 启动 后 ， 对 应 的 SPARK_MASTER_WEBUI_PORT 端口 号 由 于 已 经 被 
占用 ， 因 此 会 自动 递增 ， 即 站 7078 的 端口 号 ， 对 应 新 的 Master 的 地 址 和 之 前 的 Master 实 
例 ， 在 端口 号 上 是 不 一 样 的 。 

2. Master HA 源 代码 解析 

这 部 分 内 容 是 在 前 面 Master 源 代码 解析 的 基础 之 上 ， 进 一 步 详细 分 析 与 Master HA 相关 
的 源 代码 。 

Master 除了 继承 ThreadSafeRpcEndpoint， 可 以 作为 RPC 通信 终端 使 用 外 ， 还 继承 了 
LeaderElectable。LeaderElectable 是 一 个 特质 ， 代 码 如 下 。 




















1 @ DeveloperApi 

2 trait LeaderElectable | 

3. def electedLeader( ) 

加 def revokedLeadership( ) 
S| 





LeaderElectable 特质 包含 了 两 个 接口 ， 分 别 是 为 领导 选中 处 理 接口 和 废除 领导 层 的 处 理 
接口 。 
在 Master 中 ， 与 HA 相关 的 几 个 变量 代码 如 下 。 








// 初 始 状 态 设 置 为 RecoveryState. STANDBY 

private var state = RecoveryState. STANDBY 

//Master HA 中 用 于 持久 化 各 种 信息 的 持久 化 引擎 
Private var persistenceEngine : PersistenceEngine = _ 
//Master HA 中 用 于 领导 选举 的 代理 


private var leaderElectionAgent:LeaderElectionAgent = _ 


























和 


这 两 个 变量 的 设置 位 于 onStart 方法 中 ， 具 体 代 码 如 下 。 








1. 
2 
4. 
Sa 
6. 
a 
8. 
多 
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val serializer = new JavaSerializer( conf) 
// 根 据 恢复 模式 设置 持久 化 引擎 和 领导 选举 代理 
val (persistenceEngine_,leaderElectionAgent_) = RECOVERY_MODE match | 
case "ZOOKEEPER" => 
logInfo( " Persisting recovery state to ZooKeeper" ) 
// 构 建 一 个 ZooKeeper 恢复 模式 的 工厂 实例 ， 
// 通 过 该 工厂 实例 构建 出 持久 化 引擎 和 领导 选举 代理 
val zkFactory = 














new ZooKeeperRecoveryModeFactory ( conf, serializer) 
(zkFactory. createPersistenceEngine( ) ,zkFactory. createLeaderElectionAgent( this ) ) 
case " FILESYSTEM" => 
// 构 建 一 个 基于 文件 系统 恢复 模式 的 工厂 实例 ， 
// 通 过 该 工厂 实例 构建 出 持久 化 引擎 和 领导 选举 代理 


val fsFactory = 








new FileSystemRecoveryModeFactory ( conf, serializer ) 
(fsFactory. createPersistenceEngine( ) ,fsFactory. createLeaderElectionAgent( this) ) 
case "CUSTOM" => 
// 通 过 自 定义 的 用 于 恢复 的 工厂 类 名 ,构造 出 工厂 实例 ， 
// 通 过 该 工厂 实例 构建 出 持久 化 引擎 和 领导 选举 代理 
val clazz = Utils. classForName( conf. get( "spark. deploy. recoveryMode. factory" ) ) 








val factory = clazz. getConstructor( classOf[ SparkConf | ,classOf[ Serializer | ) 
. newInstance( conf ,serializer) 
. asInstanceOf[ StandaloneRecoveryModeFactory | 
(factory. createPersistenceEngine( ) ,factory. createLeaderElectionAgent(this) ) 
// 默 认 情 况 下 的 恢复 模式 
case _ => 
(new BlackHolePersistenceEngine( ) ,new MonarchyLeaderAgent( this) ) 
| 
persistenceEngine = persistenceEngine_ 


leaderElectionAgent = leaderElectionAgent_ 





从 代码 中 可 以 看 出 ， 当 前 的 RECOVERY_MODE 有 4 种 (包括 默认 的 模式 NONE) ， 分 
别 对 应 ZOOKEEPER、FILESYSTEM 和 自 定义 CUSTOM 。 每 种 模式 下 都 会 构建 出 一 个 对 应 的 
工厂 实例 ， 由 该 工厂 实例 负责 构建 最 终 使 用 的 持久 化 引擎 和 领导 选举 代理 。 

对 应 配置 恢复 模式 的 配置 属性 的 代码 如 下 。 





private val RECOVERY_MODE = conf. get( " spark. deploy. recoveryMode" , " NONE" ) 


各 种 模式 下 都 会 持久 化 集群 中 的 各 种 元 数据 信息 ， 包 含 Application、Driver 和 Worker。 
下 面 分 别针 对 这 4 种 模式 解析 其 选举 机 制 和 持久 化 过 程 。 

(1) ZOOKEEPER 恢复 模式 

ZooKeeper 提供 了 一 种 领导 选举 的 机 制 ， 通 过 该 机 制 ， 可 以 保证 集群 中 只 有 一 个 Master 
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处 于 RecoveryState. Active 状态 ， 其 他 的 Master 则 处 于 RecoveryState. Standby 状态 。 当 处 于 
RecoveryState. Active 状态 的 Master 结 点 出 现 故障 时 ，ZooKeeper 选举 机 制 会 保证 选举 出 新 的 
Master 结 点 。 

Spark 并 不 直接 使 用 ZooKeeper 的 API， 而 是 使 用 在 ZooKeeper 上 进一步 封装 的 Curator， > 
使 用 的 类 如 下 所 示 。 








1. import org. apache. curator. framework. CuratorFramework 


2. import org. apache. curator. framework. recipes. leader. | LeaderLatchListener, LeaderLatch| 





CuratorFramework 提供 了 high - level 的 API， 极 大 地 简化 了 ZooKeeper 的 使 用 ， 并且 在 
ZooKeeper 上 添加 了 很 多 特性 ， 包 括 以 下 几 个 。 

1) 自动 连接 管理 : 连接 到 ZooKeeper 的 Client 可 能 会 连接 中 断 ， 而 Curator 会 处 理 这 种 
情况 ， 也 就 是 说 ， 对 Client 来 说 自动 重 连 是 透明 的 。 

2) 简洁 的 API: 简化 了 原生 态 的 ZooKeeper 的 方法 、 事 件 等 ， 提 供 了 更 易于 使 用 的 接口 。 

3) Recipe 的 实现 如 下 。 

e Leader 的 选择 。 

。 共享 锁 。 

。 缓存 和 监控 。 

e 分 布 式 的 队列 。 
分 布 式 的 优先 队列 。 

CuratorFrameworks 通过 CuratorFrameworkFactory 来 创建 线程 安全 的 ZooKeeper 的 实例 。 

在 启动 ZooKeeper 的 选举 代理 类 ZooKeeperLeaderElectionAgent 时 ， 会 执行 start 方法 ,在 
该 方法 中 ， 通 过 CuratorFrameworkFactory. newClient 方法 来 创建 ZooKeeper 的 实例 ， 可 以 传人 
不 同 的 参数 来 对 实例 进行 完全 控制 。 获 取 实 例 后 ， 必 须 通过 start( ) 来 启动 这 个 实例 ， 在 结 
束 时 ,需要 调用 close( ) 。 

对 应 构建 的 代码 封装 在 SparkCuratorUtil 类 中 ， 代 码 如 下 。 























1 def newClient( 

多 conf: SparkConf, 
3 水 UrlConf:String = " spark. deploy. zookeeper. url" ) :CuratorFramework = | 
4 val ZK_URL = conf get( zkUrlConf) 

3, // 通 过 CuratorFrameworkFactory. newClient 方法 来 创建 ZooKeeper 的 实例 
6 

7 

8 

9 





val zk = CuratorFrameworkFactory. newClient( ZK_URL, 
ZK_SESSION_TIMEOUT_MILLIS,ZK_CONNECTION_TIMEOUT_MILLIS, 
new ExponentialBackoffRetry( RETRY_WAIT_ MILLIS, MAX_RECONNECT_ATTEMPTS) ) 
// 构 建 后 调用 start( ) 方 法 来 启动 








10. zk. start( ) 
11. zk 
DD 
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接口 ， 具 体 代码 如 下 。 


i 
2 
3. 
4. 
5. 
6. 
元 
8. 
9. 


private def updateLeadershipStatus( isLeader:Boolean ) | 

if (isLeader && status == LeadershipStatus. NOT_LEADER ) | 
status = LeadershipStatus. LEADER 
// 被 选中 为 领导 
masterInstance. electedLeader( ) 

| else if ( lisLeader && status == LeadershipStatus. LEADER ) | 
status = LeadershipStatus. NOT_LEADER 

/被 废除 领导 资格 


masterInstance. revokedLeadership( ) 


SS 


11. } 


当 被 选中 为 Leader 时 ，masterInstance. electedLeader( ) 接口 会 向 Master 发 送 ElectedLeader 
消息 ， 然 后 在 receive 方法 中 处 理 该 消息 ， 具 体 代 码 如 下 。 


override def receive:PartialFunction| Any, Unit | = | 


// 被 选中 为 领导 





1 

义 

3 case ElectedLeader => | 

4 // 通 过 持久 化 引擎 来 读 取 持 和 久 化 在 ZooKeeper 中 的 数据 ， 

Sh // 包 括 Application .Driver 和 Worker 

6 val (storedApps,storedDrivers ,stored Workers )= persistenceEngine. readPersistedData( rpcEnv) 
7. /根据 恢复 的 数据 设置 当前 Master 结 点 的 状态 

8 state =if (storedApps. isEmpty && storedDrivers. isEmpty && storedWorkers. isEmpty ) | 
9 RecoveryState. ALIVE 

10. | else | 








11. RecoveryState. RECOVERING 

| } 

ls logInfo( "I have been elected leader! New state:" + state) 

14. // 当 处 于 恢复 过 程 中 时 ,调用 beginRecovery 方法 开始 恢复 ,同时 启动 定时 机 制 
Ss // 周 期 性 地 向 自己 发 送 CompleteRecovery 消息 

16. if (state == RecoveryState. RECOVERING) | 

并 又 beginRecovery( storedApps ,storedDrivers , storedWorkers ) 

18. recoveryCompletionTask = forwardMessageThread. schedule(new Runnable | 
19. override def run( ) :Unit = Utils. tryLogNonFatalError | 

20. self. send( CompleteRecovery ) 

Zl | 

2 1 , WORKER_TIMEOUT_MS, TimeUnit. MILLISECONDS) 

2 } 

24. | 


其 中 ， 持 久 化 引擎 对 应 为 ZooKeeperPersistenceEngine 类 ， 在 该 类 中 实现 了 将 集群 的 元 数 
据 信息 持久 化 / 反 持 久 化 到 ZooKeeper 的 指定 路 径 下 。 
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(2) FILESYSTEM 恢复 模式 
在 这 种 模式 下 ， 选 举 机 制 比较 简单 ，Master 启动 即 认为 被 选举 为 领导 。 对 应 的 持久 化 引 
擎 只 是 将 持久 化 / 反 持 久 化 的 位 置 改 成 了 本 地 文件 系统 ， 也 就 是 将 集群 中 的 这 些 元 数据 信息 
保存 到 本 地 文件 系统 ， 恢 复 时 也 从 本 地 文件 系统 读 取 。 c) 
(3) CUSTOM 恢复 模式 证 2 
这 是 提供 用 户 自 定义 恢复 Master 元 数据 信息 的 一 种 模式 。 通 过 前 面 的 分 析 可 知 ， 当 使 用 自 定 和 
义 恢复 模式 时 ， 需 要 提供 一 个 工厂 类 ， 相 应 的 ， 该 工厂 类 中 必须 提供 构建 持久 化 引擎 和 领导 选举 
代理 的 两 个 接口 。 由 前 面 的 代码 可 知 ， 自 定义 的 工厂 类 名 在 " spark. deploy. recoveryMode. factory" 
配置 属性 中 设置 。 
(4) NONE 恢复 模式 
这 是 默认 的 恢复 模式 ， 这 种 模式 下 不 会 持久 化 集群 的 元 数据 信息 ，Master 启动 后 即 认为 
分 析 完 4 种 恢复 模式 之 后 ， 最 后 给 出 与 Master HA 相关 的 一 些 配置 属性 ， 如 表 3-23 
所 示 。 


























表 3-23 与 Master HA 相关 的 一 些 配置 属性 


配置 属性 默认 值 描 述 
恢复 模式 ( Master 重新 启动 的 模式 ) ， 有 以 下 4 种 。 
1 ) ZooKeeper 








spark. deploy. recoveryMode NONE 2) FileSystem 
3) CUSTOM 
4) NONE 
spark. deploy. zookeeper. url ZooKeeper 的 Server 地 址 
spark. deploy. zookeeper. dir /spark ZooKeeper 保存 集群 元 数据 信息 的 文件 目录 ， 包 括 Application 、Driver 和 Worker 























Es Spark on YARN 的 部 署 模型 
部 署 框 架 





1. YARN 框架 解析 

YARN 是 Hadoop 2.0 系统 上 的 资源 统一 管理 平台 ， 其 主要 作用 是 实现 集群 资源 的 统一 
管理 和 调度 ， 它 的 基本 设计 思想 是 将 MRv1 中 的 JobTracker 拆 分 成 两 个 独立 的 服务 : 一 个 全 
局 的 资源 管理 器 ResourceManager (RM) 和 每 个 应 用 程序 特有 的 ApplicationMaster (AM ) 。 

通常 ， 当 集群 中 存在 多 种 计算 框架 时 ， 使 用 YARN 统一 管理 资源 要 比 SparkStandalone 
更 合适 ， 更 利于 资源 的 合理 调度 与 充分 利用 。 











说 明 : 在 集群 中 只 需 启 动 YARN 服务 ， 通 常 底层 也 使 用 HDFS 存储 系统 ， 因 此 对 应 也 启动 HDFS 服务 。 
此 外 ，Spark Standalone 部 署 时 的 Master 和 Worker 在 次 辑 上 的 对 应 组 件 已 经 由 YARN 框架 提供 ， 因 此 不 
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需要 再 启动 ， 也 就 是 说 ，Spark on YARN 部 署 时 ， 只 需要 提供 可 以 提交 Spark 应 用 的 客户 端 即 可 ， 之 后 
提交 的 应 用 程序 由 YARN 框架 负责 调度 、 执 行 及 监控 等 。 





和 Spark Standalone 集群 一 样 ， 在 资源 管理 调度 上 ，YARN 也 采用 Master/Slave 结构 ， 在 
整个 资源 管理 框架 中 ，ResourceManager 对 应 Master，NodeManager 对 应 Slave。 其 中 ，Re- 
sourceManager 负责 各 个 NodeManager 资源 的 统一 管理 和 调度 ，NodeManager 则 负责 启动 任务 ， 
以 及 各 个 任务 间 的 具体 资源 的 隔离 。YARN 框架 如 图 3-7 所 示 。 
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图 3-7 Hadoop YARN 框架 的 基本 结构 

下 面 参考 《Hadoop 技术 内 幕 : 深入 解析 YARN 的 架构 设计 和 实现 原理 》 一 书 ,简单 描 
述 框架 中 的 主要 组 件 。 

(1) ResourceManager (RM) 

RM 是 一 个 全 局 的 资源 管理 带 ， 负 责 整个 系统 的 资源 管理 和 分 配 。 它 主要 由 两 个 组 件 构 
成 : 调度 器 (Scheduler) 和 应 用 程序 管理 器 ( Applications Manager，ASM)。 

1) 调度 器 。 调 度 器 根据 容量 、 队 列 等 限制 条 件 〈 如 每 个 队列 分 配 一 定 的 资源 ， 最 多 执 
行 一 定数 量 的 作业 等 ) ， 将 系统 中 的 资源 分 配给 各 个 正在 运行 的 应 用 程序 。 

需要 注意 的 是 ， 该 调度 器 是 一 个 “ 纯 调度 器 ”， 它 不 再 从 事 任何 与 具体 应 用 程序 相关 的 
工作 ， 比 如 不 负责 监控 或 者 跟踪 应 用 的 执行 状态 等 ， 也 不 负责 重新 启动 因应 用 执行 失败 或 者 
硬件 故障 而 产生 的 失败 任务 ， 这 些 均 交 由 应 用 程序 相关 的 ApplicationMaster 完成 。 调 度 器 仅 
根据 各 个 应 用 程序 的 资源 需求 进行 资源 分 配 ， 而 资源 分 配 单位 用 一 个 抽象 概念 “资源 容器 ” 
(Resource Container， 简 称 Container) 来 表示 ，Container 是 一 个 动态 资源 分 配 单 位 ， 它 将 内 
存 、CPU 、 磁 盘 和 网 络 等 资源 封装 在 一 起 ， 从 而 限定 每 个 任务 使 用 的 资源 量 。 此 外 ， 该 调度 
需 是 一 个 可 插 拔 的 组 件 ， 用 户 可 根据 自己 的 需要 设计 新 的 调度 器 ，YARN 提供 了 多 种 直接 可 
用 的 调度 右 ， 如 Fair Scheduler 和 Capacity Scheduler 等 。 

2) 应 用 程序 管理 器 。 应 用 程序 管理 器 负责 管理 整个 系统 中 所 有 的 应 用 程序 ， 包 括 应 用 
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程序 提交 、 与 调度 器 协商 资源 以 启动 ApplicationMaster， 以 及 监控 ApplicationMaster 的 运行 状 
态 并 在 失败 时 重新 启动 它 等 。 

(2) ApplicationMaster (AM) 

用 户 提交 的 每 个 应 用 程序 均 包 含 1 个 AM， 主 要 功能 包括 以 下 几 个 。 

e 与 RM 调度 器 协商 以 获取 资源 (用 Container 表示 ) 。 

。 将 得 到 的 任务 进一步 分 配给 内 部 任务 。 

。 与 NM 通信 以 启动 /停止 任务 。 

e 监控 所 有 任务 的 运行 状态 ， 并 在 任务 运行 失败 时 重新 为 任务 申请 资源 以 重启 任务 。 

当前 YARN 自 带 了 两 个 AM 实现 ， 一 个 是 用 于 演示 AM 编写 方法 的 实例 程序 distributed- 
shell， 它 可 以 申请 一 定数 目的 Container， 以 并 行 运行 一 个 Shell 命令 或 者 Shell 脚本 ; 另 一 个 
是 运行 MapReduce 应 用 程序 的 AM-MRAppMaster， 此 外 ， 一 些 其 他 的 计算 框架 对 应 的 AM 正 
在 开发 中 ， 如 Open MPI、Spark 等 。 

(3) NodeManager (NM ) 

NM 是 每 个 结 点 上 的 资源 和 任务 管理 器 ， 一 方面 ， 它 会 定时 地 向 RM 汇报 本 结 点 上 的 资 
源 使 用 情况 和 各 个 Container 的 运行 状态 ; 另 一 方面 ， 它 接收 并 处 理 来 自 AM 的 Container 启 
动 /停止 等 各 种 请 求 。 

(4) Container 

Container 是 YARN 中 的 资源 抽象 ， 它 封装 了 某 个 结 点 上 的 多 维度 资源 ， 如 内 存 、CPU、 
人 磁盘 和 网 络 等 ， 当 AM 向 RM 申请 资源 时 ，RM 为 AM 返回 的 资源 便 是 用 Container 表示 的 。 
YARN 会 为 每 个 任务 分 配 一 个 Container， 且 该 任务 只 能 使 用 该 Container 中 描述 的 资源 。 

需要 注意 的 是 ，Container 不 同 于 MRv1 中 的 Slot， 它 是 一 个 动态 资源 划分 单位 ， 是 根据 
应 用 程序 的 需求 动态 生成 的 。 目 前 ，YARN 仅 支 持 CPU 和 内 存 两 种 资源 ， 且 使 用 了 轻 量 级 
资源 隔离 机 制 Cgroups 来 进行 资源 隔离 。 

2. YARN 上 应 用 程序 开发 解析 

当 使 用 Spark on YARN 方式 提交 Spark 应 用 程序 时 ，Spark 需要 实现 YARN 应 用 程序 接 
入 的 接口 要 求 。 关 于 在 YARN 上 开发 应 用 程序 的 相关 内 容 ， 可 以 参考 《Hadoop 技术 内 幕 : 
深入 解析 YARN 的 架构 设计 和 实现 原理 》 一 书 的 相关 章节 ， 这 里 仅 给 出 简单 的 分 析 ， 以 便 
后 续 对 Spark on YARN 相关 部 分 进行 解析 。 

用 户 在 YARN 上 开发 应 用 时 ， 需 要 实现 以 下 3 个 模块 。 

1) Application Client: 负责 将 应 用 程序 提交 到 YARN 上 ， 同 时 ， 监 控 应 用 的 运行 状态 ， 
控制 应 用 的 运行 。 

2) Application Master (AM) : 负责 整个 应 用 的 运行 控制 ， 包 括 向 YARN 注册 应 用 、 申 
请 资源 和 局 动容 器 等 ， 其 中 ， 容 器 是 抽象 的 资源 分 配 单位 。 

3) Application Worker: 负责 应 用 的 实际 工作 ， 并 不 是 所 有 的 应 用 都 需要 编写 Worker。 
NodeManager 启动 AM 发 送 过 来 的 容器 ， 容 器 内 部 封装 了 该 应 用 Worker 运行 所 需 的 资源 和 启 
动 的 命令 。 

要 实现 上 述 模 块 ， 涉 及 以 下 3 个 RPC 协议 。 

1) ApplicationClientProtocol: Client -RM 之 间 的 协议 ， 主 要 用 于 应 用 的 提交 。 

2) ApplicationMasterProtocol: AM - RM 之 间 的 协议 ，AM 通过 该 协议 向 RM 注册 并 申请 
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资源 。 

3) ContainerManagementProtocol: AM - NM 之 间 的 协议 ，AM 通过 该 协议 控制 NM 启动 容 央 。 

3. Spark on YARN 框架 解析 

Spark on YARN 部 署 框架 的 解析 ， 实 际 上 大 部 分 已 经 由 YARN 框架 本 身 决定 了 ， 因 此 对 
应 的 部 署 框架 仅 需要 关注 如 何 将 Spark 应 用 程序 提交 到 YARN 框架 上 。 

通过 比较 Spark Standalone 与 YARN 框架 上 应 用 程序 本 身 的 组 成 结构 ， 可 以 看 到 两 者 都 是 
采用 类 似 集群 Master/ Slave 部 署 的 这 种 结构 。 即 ， 无 论 是 YARN 还 是 Spark Standalone 集群 ， 应 
用 程序 本 身 也 带 有 Master/ Slave 形式 的 组 成 结构 ， 对 应 为 应 用 程序 的 驱动 程序 和 应 用 程序 被 拆 
分 的 各 个 逻辑 执行 单位 〈 可 以 抽象 对 应 到 Task 或 Executor) ， 其 中 驱动 程序 部 分 对 应 Master， 
而 各 个 逻辑 执行 单位 对 应 Slave。 将 计算 与 资源 拆 分 开 ， 两 者 可 以 对 等 比较 ， 如 图 3-8 所 示 。 
































Container Node Manager 
| (容器 ) | | ( 结 点 管理 器 ) 
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图 3-8 包含 了 两 种 层面 上 的 Master/Slave 框架 ， 左边 对 应 的 是 应 用 层面 的 ， 有 作为 Mas- 
ter 角色 的 AppMstr 和 作为 Slave 角色 的 Container (具体 运行 时 )。 右 边 对 应 的 是 资源 层面 ， 
同样 有 作为 Master 角色 的 ResourceMstr 和 作为 Slave 角色 的 Node Manager。 如 果 继 续 扩展 的 
话 ， 计 算 、 资 源 和 存储 等 各 个 层面 ， 甚 至 于 在 计算 层面 上 也 可 以 由 计算 时 调度 对 象 的 粒度 不 
同 而 进一步 分 层 ， 这 些 层面 都 可 以 采用 这 种 中 心 化 的 Master/Slave 框架 来 实现 分 布 式 的 计 
算 、 资 源 管理 与 分 配 和 存储 管理 等 等 。 中 间 的 Request/ Response 是 计算 的 应 用 与 资源 管理 间 
的 资源 申请 与 分 配 ， 对 应 可 以 理解 为 计算 与 资源 两 个 解 耦 之 后 的 组 件 间 的 交互 。 











应 用 程序 的 部 署 


本 节 主 要 分 析 如 何 将 Spark 应 用 程序 提交 到 YARN 上 ， 当 Spark 的 应 用 程序 启动 之 后 ， 
应 用 内 部 的 交互 和 Spark Standalone 是 一 致 的 。 
下 面 从 前 面 的 分 析 中 抽取 出 Spark on YARN 模式 部 署 的 实例 构建 信息 ， 如 表 3-24 所 示 。 
表 3-24 脚本 中 的 参数 与 主 资源 间 的 对 应 关系 
部 署 模式 ( master) 实例 对 应 的 类 备 注 











_taskScheduler:YarmScheduler 本 
YARN Client YARN 集群 管理 器 + Client 部 署 
_schedulerBackend :YamClientSchedulerBackend 

















_taskScheduler: YarnClusterScheduler 
YARN Cluster YARN 集群 管理 器 + Cluster 部 署 


_schedulerBackend :YarnClusterSchedulerBackend 
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和 Spark Standalone 一 样 ，Spark on YARN 也 存在 两 种 部 署 模式 ， 包 括 Client 部 署 模式 和 
Cluster 部 署 模式 。 在 Client 的 部 署 模式 提交 时 ， 直 接 在 提交 点 运行 应 用 程序 ， 即 对 应 的 驱 
动 程序 是 在 当前 结 点 启动 的 。 而 在 Spark on YARN 模式 部 署 下 ， 需 要 通过 ApplicationMas- 
ter 管理 用 户 应 用 程序 ， 因 此 在 该 模式 下 ，Client 与 Cluster 两 种 部 署 模式 下 在 不 同 结 点 启 
动 驱 动 程序 的 差异 ， 也 就 对 应 了 两 种 部 署 模式 下 在 集群 中 启动 的 ApplicationMaster 的 职责 
差异 。 

下 面 解析 这 两 种 部 署 模式 下 ，Spark 应 用 程序 提交 过 程 的 关键 源 代码 。 

1.， 以 Client 的 部 署 模式 提交 应 用 程序 

当 以 Client 的 部 署 模式 提交 应 用 程序 时 ， 使 用 YarnScheduler 与 YarnClientSchedulerBack- 
end， 在 SparkContext 构建 出 SparkDeploySchedulerBackend 实例 后 ， 然 后 调用 该 实例 的 start 方 
法 ,关键 代码 如 下 。 





































































































1 

2 x* 创建 一 个 YARN 客户 端 , 用 于 向 ResourceManager 提交 应 用 程序 

3 

4. * This waits until the application is running. 

5. */ 

6. override def start( ) | 

ts 

8. /应 用 程序 参数 解析 

9 val args = new ClientArguments( argsArrayBuf toArray ,conf) 

10. totalExpectedExecutors = args. numExecutors 

11. 

2 // 构 建 org. apache. spark. deploy. yarn. Client, 并 通过 该 类 提交 应 用 程序 

13. client = new Client( args ,conf) 

14. appld = client. submitApplication( ) 

15. 

16. //SPARK -8687 :在 我 们 初始 化 driver 调度 后 台 程 序 时 候 ,在 driver 需 设 置 executor 的 
属性 ,确保 所 有 必要 的 属性 都 已 经 设置 。 

17. super. start( ) 

18. 

19. waitForApplication( ) 

20. 

il 

2 } 





从 以 上 代码 中 可 以 看 出 ， 关 键 代码 位 于 “org. apache. spark. deploy. yarn. Client”， 该 类 负 
责 应 用 程序 的 提交 。 

2. 以 Cluster 的 部 署 模式 提交 应 用 程序 

在 集群 管理 器 为 YARN 、 部 署 模 式 为 Cluster 时 ，childMainClass 及 对 应 的 mainClass 的 设 
置 如 表 3-4 所 示 。 

关于 内 部 的 一 些 环境 设置 等 细节 ， 大 家 可 以 查看 具体 的 代码 实现 。 
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在 Cluster 部 署 模式 下 提交 时 ， 封 装 的 主 类 为 " org. apache. spark. deploy. yarn. Client" ， 同 





时 用 户 提 交 的 应 用 程序 的 主 类 “args. mainClass” 作 为 参数 被 封装 到 该 主 类 中 。 
当主 类 为 "org. apache. spark. deploy. yarn. Client" 时 ， 执 行人 口 点 为 该 类 的 main 方法 ， 具 








体 代 码 如 下 。 
1 def main( argStrings:Array[ String | ) | 
2 ee 
3. ”//Client 的 参数 解析 
4 val args =new ClientArguments( argStrings ,sparkConf) 
Se 
6 // 和 Client 部 署 模式 一 样 , 在 入 口 点 实例 化 一 个 Client 实例 ,并 运行 run 方法 
了 new Client( args ,sparkConf). run( ) 
8 | 











结合 前 面 以 Client 的 部 署 模式 提交 应 用 程序 ， 可 以 看 到 ， 使 用 Client 部 署 模式 提交 与 使 
用 Cluster 部 署 模式 提交 最 终 都 会 实例 化 一 个 " org. apache. spark. deploy. yarn. Client" 实例 。 

而 在 调用 该 实例 的 run 方法 时 ， 和 Client 部 署 模式 一 样 ， 也 会 提交 应 用 程序 。 具 体 代码 
如 下 。 


1 def run( ) :Unit = | 

2. /通过 Client 实例 来 提交 应 用 程序 
区 this. appId = submitApplication( ) 
4 

9 




















| 


3. Client 与 Cluster 两 种 部 署 模式 下 调用 的 submitApplication 方法 解析 
从 Client 与 Cluster 两 种 部 署 模 式 的 入 口 源 代码 分 析 可 得 ， 两 种 模式 下 最 终 都 调用 了 
Client 实例 的 submitApplication 方法 ， 因 此 继续 分 析 该 方法 ， 具 体 源 代码 如 下 。 




















1 [水 水 

2 * 问 ResourceManager 提交 一 个 应 用 程序 ,来 运行 ApplicationMaster 

3 

4 水 

5 * The stable Yarn API provides a convenience method (YarnClient#createApplication ) for 
6 * creating applications and setting up the application submission context. This was not 
¥ * available in the alpha API. 

8 */ 

9 def submitApplication( ) :ApplicationId = | 

10. var appld: Applicationld = null 

11. try | 

[2 


13. // 利 用 YARN 提供 的 API， 





第 3 章 部 署 模 式 (Deploy) 解析 

















14. // 创 建 提交 客户 端 org. apache. hadoop. yarn. client. api. YarnClient 

| yarnClient. init( yarnConf) 

16. yarnClient. start( ) 

jh O) 
ee 

19. 

20. // 从 RM 中 获取 一 个 新 的 应 用 程序 ,并 处 理 反馈 信息 

2 val newApp = yarnClient. createApplication( ) 

22 

2 

2 // 为 AM 创建 启动 所 需 的 上 下 文 

2 val containerContext = createContainerLaunchContext( newAppResponse ) 
26. val appContext = createApplicationSubmissionContext( newApp ,containerContext ) 
2 

28. // 创 建 上 下 文 等 信息 后 最 终 提交 并 监控 应 用 程序 

29. 

30. yarnClient. submitApplication( appContext ) 

31. appld 

3 天 | catch | 

33. 

34. } 

3 党 : } 





查看 第 27 行 中 createContainerLaunchContext 方法 的 关键 源 代码 ， 如 下 所 示 。 








1 

2 * 创建 ContainerLaunchContext, 用 于 启动 ApplicationMaster 的 容 需 

3 

4. * This sets up the launch environment ,java options ,and the command for launching the AM. 
5 */ 

6. private def createContainerLaunchContext( newAppResponse :GetNewApplicationResponse) 
a :ContainerLaunchContext = | 

0 

9. /设置 执行 的 用 户主 类 

10. val userClass = 

11. if (isClusterMode) | 

12 Seq(" ——class" ,YarnSparkHadoopUtil. escapeForShell( args. userClass ) ) 

IS | else | 

14. Nil 

15. } 

16.: 


jl // 设 置 AM( ApplicationMaster) 容器 执行 的 主 类 


18. val amClass = 
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19. if (isClusterMode ) | 

20. Utils. classForName( " org. apache. spark. deploy. yarn. ApplicationMaster" ). getName 
2 | else | 

2 Utils. classForName( " org. apache. spark. deploy. yarn. ExecutorLauncher" ). getName 
23: } 

24. 

25. | 


从 第 10 行 与 第 18 行 代码 可 知 ， 在 Client 模式 下 ，AM 的 类 为 ExecutorLauncher， 对 应 用 户 
主 类 为 Nl， 而 在 Cluster 模式 下 ，AM 的 类 为 "org. apache. spark. deploy. yarn. ApplicationMaster" ， 
对 应 用 户主 类 为 用 户 提 交 的 应 用 程序 的 主 类 ， 即 此 时 将 用 户 提交 的 主 类 封装 到 了 "org 
apache. spark. deploy. yarn. ApplicationMaster" 中 。 对 应 在 ExecutorLauncher 的 入 口 方 法 中 会 调用 " 
org. apache. spark. deploy. yarn. ApplicationMaster" 的 入 口 方 法 。 

"org. apache. spark. deploy. yarn. ApplicationMaster" 对 应 的 入 口 方 法 中 的 关键 代码 如 下 。 











final def run( ) :Int = | 


1 

2 

3 // 根 据 部 署 模 式 运 行 Driver 或 Executor 加 载 右 
4 if (isClusterMode) | 

到 runDriver( securityMgr ) 

6 | else | 

区 runExecutorLauncher( securityMgr ) 

8 | 

Ome 





在 runDriver 与 runExecutorLauncher 方法 中 都 会 构建 RPC 通信 终端 并 调用 register- 
AM ， 最 终 通过 YARN API 提供 的 org. apache. hadoop. yarn. client. api. AMRMClient 向 RM 注册 
用 户 的 ApplicationMaster。 

因此 在 申请 提交 应 用 程序 并 启动 之 后 ," org. apache. spark. deploy. yarn. ApplicationMaster" 
会 在 当前 提交 结 点 〈Client 部 署 模式 ) 或 集群 分 配 的 茶 个 结 点 〈Cluster 部 署 模式 ) 中 的 容 
顺 内 启动。 

下 面 继续 分 析 AM 启动 之 后 ， 启 动 实际 执行 的 Executor 相关 代码 的 源 代码 解析 。 

4. Client 与 Cluster 两 种 部 署 模式 下 调用 的 Executor 启动 的 解析 

可 以 从 Executor 在 集群 中 的 通信 接口 出 发 解析 源 代码 ， 接 口 的 具体 代码 如 下 。 



































区 
* Executor 所 使 用 的 可 插 拔 接口 

* A pluggable interface used by the Executor to send updates to the cluster scheduler. 
*/ 

private[ spark | trait ExecutorBackend | 
def statusUpdate( taskld : Long, state: TaskState , data: ByteBuffer ) 

| 


SE A Per 
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Executor 所 使 用 的 可 插 拔 接口 的 具体 子 类 包含 LocalBackend 、MesosExecutorBackend 和 


CoarseGrainedExecutorBackend， 分 别 用 于 本 地 通信 、Mesos 集群 模式 下 的 通信 和 其 他 模式 下 
的 通信 。 














Spark on YANR 集群 中 使 用 CoarseGrainedExecutorBackend 作为 Executor 的 通信 端口 ， 由 








AM 负责 向 RM 申请 资源 并 发 送 到 RM， 最 终 由 RM 负责 启动 容器 ， 执 行 CoarseGrainedExecu- 
torBackend 。 











从 通信 接口 出 发 并 查看 CoarseGrainedExecutorBackend 通信 端 最 终 在 Spark on YARN 集群 


中 创建 的 位 置 ， 可 以 定位 Executor 的 启动 位 置 。 











或 者 通过 逐步 源 代码 分 析 去 查看 ， 即 通过 注册 AM 之 后 的 源 代码 逐步 分 析 。 
在 Client 与 Cluster 两 种 模式 下 ， 都 会 注册 AM， 即 调用 registerAM， 对 应 的 具体 代码 








如 下 。 







































































1. private def registerAM( 

2 _rpcEnv: Rpcknyv, 

3 driverRef: RpcEndpointRef, 

加 uiAddress: String, 

3 securityMgr:SecurityManager) = | 

6. 2 

7. /通过 YamRMClient 实例 注册 ,该 实例 中 调用 AMRMClient 实例 向 RM 注册 ， 
8. // 注 册 成 功 后 返回 YarnAllocator 实例 
9 allocator = client. register( driverUzl ， 

10. driverRef, 

11. yarnConf, 

12. _sparkConf, 

Us uiAddress, 

14. historyAddress, 

15. securityMgr) 

16. 

1 // 调 用 YarnAllocator 实例 的 分 配 资源 方法 ,在 该 方法 中 会 申请 资源 并 启动 
18. //Executor 通信 接口 具体 子 类 

19. allocator. allocateResources( ) 

20. reporterThread = launchReporterThread( ) 
wl 





Executor 通信 接口 的 具体 子 类 为 CoarseGrainedExecutorBackend， 执 行 的 命令 封装 在 Exec- 


utorRunnable 类 。 


同样 的 ，Sparkon Mesos 的 部 署 模型 与 Spark on YARN 类 似 ， 仅 仅 针 对 不 同 的 资源 管理 央 











Mesos 提供 的 应 用 注册 接口 ,来 接 和 用户 的 应 用 程序 。Mesos 计算 框架 是 一 个 集群 管理 器 ， 


提供 了 有 效 的、 跨 分 布 式 应 用 或 框架 的 资源 隔离 和 共享 ， 可 以 运行 Hadoop、MPI、Hypert- 














able 和 Spark。 使 用 ZooKeeper 实现 容错 复制 ， 使 用 Linux Containers 来 隔离 任务 ， 支 持 多 种 
资源 计划 分 配 。Sparkon Mesos 的 部 署 模型 与 Spark on YARN 等 其 他 部 署 模型 相 比 ， 主 要 差异 
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在 于 Mesos 本 身 的 框架 ， 以 及 对 外 提供 的 接 入 方式 等 。 在 此 不 再 费 述 。 


本 章 内 容 从 源 代 码 角度 出 发 ， 详 细 解 析 了 Spark 的 不 同 集群 框架 ， 以 及 在 这 些 框架 中 的 
不 同 部 署 情况 ， 包 括 Local 类 的 集群 部 署 、Spark Standalone 集群 部 署 、Spark on YARN 集群 
部 署 ， 以 及 Spark on Mesos 集群 部 署 下 的 实现 细节 。 








第 4 章 Spark 调 度 器 (Scheduler ) 运行 机 制 


第 4 但 ”Spark 调度 上 (Scheduler) 
运行 机 制 


Spark 调度 器 的 设计 体现 得 非常 简洁 清晰 和 高 效 ， 其 输入 是 Spark RDD， 输 出 是 Spark 执 
行 吉 (Executor) 。 正 是 Spark 调度 器 的 设计 思想 极 大 地 区 分 出 了 基于 MapReduce 模型 的 Ha- 
doop 和 基于 DAG 模型 的 Spark。 本 章 将 分 别 阐述 Spark 调度 器 各 个 重要 组 件 的 机 制 和 原理 ， 
结合 Spark 调度 器 的 源 代 码 实现 ， 详 细 解 析 Spark 调度 器 的 实现 细节 ， 主 要 内 容 包 括 Spark 
运行 核心 概念 、Spark Driver Program 剖析 、Spark 作业 (Job) 的 触发 、 高 层 的 DAG 调度 器 
(DAGScheduler) 、 底 层 的 Task 调度 器 (TaskScheduler) 和 调度 器 的 通信 终端 (Scheduler- 
Backend ) 。 





Spark 运行 的 核心 概念 











-是 Spark 运行 的 基本 对 象 SS 


根据 前 面 的 阐述 可 知 ，RDD 其 实 就 是 Spark 运行 的 基本 对 象 。 关 于 RDD 的 定义 和 运行 
机 制 ， 在 第 1 章 和 第 2 章 分 别 给 予 了 详细 阐述 。 这 里 重新 总 结 下 RDD 的 一 些 重要 特征 和 创 
建 方式 ， 以 方便 后 面 对 整 个 Spark 调度 器 (Scheduler) 的 运行 机 制 的 理解 。 
RDD 是 一 种 数据 模型 ， 与 分 布 式 的 共享 内 存 类 似 。RDD 有 以 下 几 个 特征 。 
。 是 只 读 的 内 存 数据 ， 但 可 以 持久 化 。 
e 是 可 以 分 区 的 数据 集合 。 
e 是 一 个 对 象 ， 可 以 调用 它 的 方法 执行 一 些 变换 操作 (Transformation ) ， 如 flagMap、 
filter 等 。 
。 是 可 恢复 的 。 与 数据 多 副本 的 备份 方式 不 同 ，RDD 的 恢复 可 以 通过 重复 执行 变换 操 
作 (Transformation ) 得 到 。 
e 变换 操作 (Transformation) 是 延迟 操作 ， 只 有 在 真正 需要 时 才 执 行 。 
有 下 列 两 种 方式 可 以 创建 RDD。 
e 从 持久 化 的 数据 上 创建 ， 如 硬盘 和 HDFS 上 的 文件 。 
e 从 其 他 RDD 上 通过 变换 (Transformation ) 操作 创建 。 
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说 明 : RDD 本 身 是 与 编程 语言 无 关 的 ， 既 可 以 用 Scala 语言 实现 ， 也 可 以 用 Java、Python 等 其 他 编程 语 
言 实 现 。 当 初 决定 用 Scala 就 是 因为 用 它 写 的 代码 简单 明了 。 

















Spark 运行 框架 及 各 组 件 的 基本 运行 原理 


本 章 默 认 讲解 的 内 容 都 是 基于 Spark 的 Standalone 部 署 模式 。 在 Standalone 部 署 模 式 下 ， 
Spark 比 在 YARN 和 Mesos 更 容易 使 用 ， 因 为 不 需要 其 他 的 东西 。 如 果 是 基于 Spark 来 处 理 
数据 ， 基 本 上 一 个 Spark 框架 就 可 以 了 ， 无 须 使 用 YARN 或 者 Mesos 等 (如 果 掌 握 了 Standa- 
lone 模式 ， 掌 握 Yarm 或 者 Mesos 是 没有 问题 的 ， 因 为 它们 80% 的 原理 都 是 类 似 的 ) 。 

如 图 4-1 所 示 ，SparkContext 在 创建 DAGScheduler 、TaskScheduler 、SchedulerBackend 的 
同时 还 会 向 Master 注册 程序 。 如 果 注 册 没 有 问题 的 话 ，Master 通过 Cluster Manager 会 给 这 个 
程序 分 配 资源 ， 然 后 根据 Action 触发 Job。Job 里 面 有 一 系列 RDD，DAGScheduler 从 后 往 前 
推荐 发 现 是 宽 依 赖 的 话 ， 就 划分 不 同 的 Stage 。Stage 划分 完成 之 后 ，Stage 提交 给 底层 的 调度 
吉 TaskScheduler，TaskScheduler 拿 到 这 个 Task 的 集合 。 因 为 一 个 Stage 内 部 都 是 计算 逻辑 完 
全 一 样 的 任务 ， 只 不 过 是 计算 的 数据 不 同 。TaskScheduler 就 会 根据 数据 的 本 地 性 ， 将 任务 分 
配 到 Executor 上 去 执行 。Executor 在 任务 运行 结束 或 者 出 状况 时 ， 肯 定 要 向 Driver 汇报 。 最 
后 运行 完毕 之 后 ， 关 闭 SparkContext， 同 时 其 创建 的 那些 对 象 也 要 关闭 掉 。 

















Worker 结 点 





执行 器 


Spark Context 虹 群 管理 器 
Worker 结 点 


执行 器 | 缓存 














图 4-1 Spark 运行 框架 图 


第 3 章 已 经 介绍 了 对 Driver、Worker 和 Executor 等 Spark 运行 框架 的 主要 组 件 的 基本 概 
念 ， 下 面 分 别 对 这 些 组 件 的 基本 运行 原理 给 予 更 为 详细 的 阐述 。 

Driver 是 应 用 程序 运行 时 的 核心 ， 它 负责 整个 作业 的 调度 ， 同 时 会 向 Master 申请 资源 完 
成 具体 作业 的 工作 过 程 。 所 谓 应 用 程序 ， 就 是 用 户 编写 的 Spark 代码 打包 后 的 jar 包 和 相关 
的 依赖 ， 其 中 包括 Driver 功能 的 代码 和 分 布 在 集群 中 多 个 结 点 的 Executor 代码 。Driver 是 了 驱 
动 Executor 去 工作 ，Executor 内 部 是 线程 池 并 发 地 去 处 理 数据 分 片 的 。Driver 部 分 的 代码 就 
是 Sparkconf 和 SparkContext 部 分 。SparkContext 在 创建 时 包含 很 多 内 容 ， 包 括 DAGScheduler、 
TaskScheduler 、Schedulerbackend 和 Spark - Env 等 (一 个 程序 默认 有 一 个 DAGScheduler)。 
所 以 一 个 Spark Application 通常 包含 : Driver 端的 代码 和 分 布 在 集群 中 多 个 结 点 上 的 Executor 
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的 代码 。 如 textFile、flatMap 和 map 等 可 以 产生 很 多 RDD 的 方法 是 具体 的 业务 实现 ， 也 就 是 
Executor 中 具体 要 执行 的 代码 。 所 有 的 业务 逻辑 都 是 在 具体 的 集群 Worker 上 的 Executor 上 执 
行 的 (前 提 是 代码 要 发 送 到 集群 上 )。 

Cluster Manager 是 集群 中 获取 资源 的 Web 服务 。 在 Spark 的 最 初 阶段 并 没有 YARN 模 
式 ， 也 没有 Standalone 模式 ， 资 源 管理 服务 是 Mesos ， 后 来 增加 了 YARN ， 后 来 为 了 推广 善 
及 产生 了 Standalone。 最 重要 的 特征 是 : Spark 的 Application 的 运行 不 依赖 于 Cluster Manag- 
er。 也 就 是 说 Spark 的 Application 注册 给 Master， 如 果 注 册 成 功 ，Master 提前 给 Application 
分 配 好 了 资源 ， 运 行 过 程 中 根本 不 需要 Cluster Manager 的 参与 。Cluster Manager 是 可 搬 拔 
的 。 这 种 资源 的 分 配方 式 是 粗 粒 度 的 。 集 群 中 的 具体 工作 ， 除 了 Cluster Manager 、Master 和 
资源 分 配器 外 ， 这 些 都 是 处 于 主 结 点 上 。 

Executor 是 运行 在 Worker 结 点 上 的 为 当前 应 用 程序 开启 进程 里 的 处 理 对 象 。 这 个 对 象 
负责 具体 的 Task 运行 ， 是 通过 线程 池 并 发 运行 和 线程 复 用 的 方式 。Spark 在 一 个 结 点 上 为 当 
前 的 程序 开启 一 个 JVM 进程 ，JVM 进程 是 线程 池 的 方式 ， 通 过 线程 处 理 具 体 的 Task 任务 。 
Executor 是 进程 里 的 对 象 。 一 个 Worker 默认 为 当前 的 应 用 程序 开启 一 个 Executor (可 以 配置 
多 个 ) 。Executor 靠 线程 池 中 的 线程 运行 Task 时 ， 肯 定 会 去 磁盘 或 者 内 存 中 读 写 数据 。 每 个 
Application 都 有 自己 独立 的 一 批 Executor。 

Worker 是 集群 中 任何 可 以 运行 Application 具体 的 textFile 、flatMap 、map 、filter 和 redu- 
ceByKey 等 这 些 操作 代码 的 结 点 。Weorker 上 是 不 会 运行 程序 代码 的 ，Worker 是 管理 当前 结 点 
CPU、 内 存 等 资源 的 使 用 状态 ， 它 会 接收 Master 分 配 资源 ( 即 Executor) 的 指令 ， 会 通过 
ExecutorRunner 启动 一 个 新 进程 ， 进 程 里 面 有 Executor。 为 了 便于 理解 ， 可 以 把 Cluster Man- 
ager 看 成 是 项 目 经 理 ，Worker 是 工 长 , 项目 经 理 (Cluster Manager) 会 管理 很 多 工 长 
(Worker) ， 工 长 下 面 有 很 多 工人 (Executor)。 所 以 ，Worker 管理 当前 结 点 的 计算 资源 ( 主 
要 是 CPU 和 内 存 ) ， 并 接收 Master 的 指令 ， 来 分 配 具 体 的 计算 资源 (在 新 的 进程 中 分 配 ) 。 
要 分 配 一 个 新 的 进程 做 计算 时 ，ExecutorRunner 相当 于 一 个 代理 ， 管 理 具体 新 分 配 的 进程 ， 
也 监控 具体 的 Executor 所 在 进程 运行 的 状况 。 其 实 就 是 在 ExecutorRunner 中 远程 创建 出 新 的 
进程 的 。Woker 是 一 个 进程 ， 不 会 向 Master 汇报 当前 机 器 的 CPU 和 内 存 等 信息 。Worker 发 
送 心 跳 汇 报 的 信息 只 有 Workerid。 应 用 程序 注册 成 功 时 ，Master 会 给 应 用 程序 分 配 资源 ， 分 
配 时 都 会 记录 资源 。 如 果 中 间 Executor 有 丢失 的 情况 ，Worker 要 向 Master 汇报 ， 然 后 动态 
地 调整 资源 。 






































Spark Driver Program 剖析 











2 什么 是 Spark Driver Program ) 





在 3.4.1 节 中 ,已 经 介绍 过 Spark Driver Program (以 下 简称 Driver) 是 运行 Application 
的 main 函数 ， 并 且 新 建 SparkContext 实例 的 程序 。 其 实 ， 初 始 化 SparkContext 是 为 了 准备 
Spark 应 用 程序 的 运行 环境 ， 在 Spark 中 由 SparkContext 负责 与 集群 进行 通信 、 资 源 的 申请 ， 
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以 及 任务 的 分 配 和 监控 等 。 当 Worker 结 点 中 的 Executor 运行 完毕 Task 后 ，Driver 同时 负责 
将 SparkContext 关闭 。 通 常 也 可 以 使 用 SparkContext 来 代表 驱动 程序 (Driver) 。 


Driver (或 者 SparkContext) 整体 架构 图 如 图 4-2 所 示 。 


Ee 


结果 
(Result) 
Ts RAM (内 存 ) 


(Task) Worker 结 点 










| RAM (内 存 ) | 







图 4-2 Driver (或 者 SparkContext) 整体 架构 图 


SparkContext 原理 剖析 ) 


SparkContext 是 用 户 通 往 Spark 集群 的 唯一 入 口 ， 可 以 用 来 在 Spark 集群 中 创建 RDD、 
累加 絮 (Accumulator) 和 广播 变量 ( Broadcast Variable ) 。SparkContext 也 是 整个 Spark 应 用 
程序 (Application) 中 至 关 重 要 的 一 个 对 象 ， 可 以 说 是 整个 Application 运行 调度 的 核心 (不 
下 是 指 党 页 资源 调 度 js 

SparkContext 的 核心 作用 是 初始 化 Spark 应 用 程序 运行 所 需 的 核心 组 件 ， 包 括 高 层 调度 
器 (DAGScheduler) 、 底 层 调度 器 (TaskScheduler) 和 调度 器 的 通信 终端 ( SchedulerBack- 
end) ， 同 时 还 会 负责 Spark 程序 向 Master 注册 程序 等 。 

通常 ， 为 了 测试 或 者 学 习 用 Spark 开发 一 个 Application ， 在 Application 的 main 方法 中 ， 
最 开始 几 行 编写 的 代码 一 般 总 是 这 样 的 : 首先， 会 创建 SparkConf 实例 ， 设 置 SparkConf 实例 
的 属性 以 便 覆 盖 Spark 默认 配置 文件 spark - env. sh、spark - default sh 和 log4j. properties 中 
的 参数 ; 然后，SparkConf 实例 作为 SparkContext 类 的 唯一 构造 参数 用 来 实例 化 SparkContext 
实例 对 象 。SparkContext 在 实例 化 的 过 程 中 会 初始 化 DAGScheduler 、TaskScheduler 和 Sched- 
ulerBackend， 而 当 RDD 的 action 触发 了 作业 (Job) 后 ，SparkContext 会 调用 DAGScheduler 
将 整个 Job 划分 成 几 个 小 的 阶段 (Stage ) ，TaskScheduler 会 调度 每 个 Stage 的 任务 (Task) 
应 该 如 何 处 理 。 男 外 ，SchedulerBackend 管理 整个 集群 中 为 这 个 当前 的 Application 分 配 的 计 
算 资源 ( 即 Executor) 。 

如 果 用 汽车 来 比喻 Spark Application ， 那 么 SparkContext 就 是 车 子 的 引 警 ， 而 SparkConf 
是 关于 引擎 的 配置 参数 。 




















说 明 : 只 可 以 有 一 个 SparkContext 实例 运行 在 于 一 个 JVM 内 存 中 ， 所 以 在 创建 新 的 SparkContext 实例 之 
前 ， 必 须 调用 stop 方法 停止 当前 JVM 唯一 运行 的 SparkContext 实例 。 
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| SparkContext 源 代 码 解 析 








下 面 通过 SparkContext 源 代码 的 解析 ， 来 更 深入 地 理解 SparkContext 的 原理 。 
例如 ， 用 Scala 编程 语言 开发 的 “Top N”Application 的 开头 部 分 代码 如 下 。 














// 创 建 SparkConf 对 象 

val conf = new SparkConf( ) 

/7 设置 应 用 程序 的 名 称 ,在 程序 运行 的 监控 界面 可 以 看 到 名 称 

conf setAppName( "Top N!") 

// 使 程序 运行 在 Spark 集群 

//conf. setMaster( " spark :// Master:7077" ) 

// 或 者 使 程序 运行 在 本 地 ,适合 于 机 器 配置 条 件 差 ( 如 只 有 1G 内 存 ) 的 初学 者 

conf setMaster( " local" ) 

// 创 建 SparkContext 对 象 ,通过 传人 SparkConf 实例 来 定制 Spark 运行 的 具体 配置 参数 


val sc = new SparkContext( conf) 
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11. 





SparkConf 的 部 分 关键 代码 如 下 。 




































































1. /SparkConf 负责 整个 Spark Application 的 配置 管理 ， 

2. /这 些 配置 参数 以 key - value 的 形式 存放 在 SparkConf 实例 对 象 的 内 存 中 。 

3. ”// 通 常情 况 下 ,通过 new SparkConf( ) 来 创建 一 个 SparkConf 实例 对 象 ， 

4. ”// 这 种 方式 也 会 读 取 所 有 “spark. * ”形式 的 Java 系统 属性 ， 

5. /不 过 用 代码 直接 设置 的 配置 参数 会 覆盖 系统 属性 。 

6. ”// 也 可 以 调用 new SparkConf(false) 来 忽略 外 部 Java 系统 属性 设置 的 参数 。 

7. ”//SparkConf 的 setter 方法 支持 调用 链 , 例如; 

8. //new SparkConf( ). setMaster( "local" ). setAppName("My app" ) 

9. ”// 注 意 :SparkConf 的 实例 对 象 一 旦 传 给 Spark Application ,配置 参数 就 不 能 再 动态 改变 
10. class SparkConf(loadDefaults :Boolean ) extends Cloneable with Logging | 

11. 

2 import SparkConf. _ 

13. 

14. /* * Create a SparkConf that loads defaults from system properties and the classpath */ 
15. def this( ) =this( true) 

16. 

7 private val settings = new ConcurrentHashMap[ String, String | ( ) 

18. 

19. if (loadDefaults) | 

20. //Load any spark. * system properties 

2 for ( (key,value) <- Utils. getSystemProperties if key. startsWith( "spark. " ) )| 
2 set( key ,value) 

2 } 
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// 设 置 Application 要 连接 的 Spark 集群 Master 结 点 的 URL, 例如 ; 

// -local 表示 Application 运行 在 本 地 ,有 1 个 Thread 服务 

// -local[4] 表 示 Application 运行 在 本 地 ,有 4 个 Thread 服务 

// “spatk://master:7077” 表 示 Application 运行 在 Spark Standalone 集群 模式 
def setMaster( master: String) :SparkConf = | 











set(" spark. master" ,master ) 











/设置 应 用 程序 的 名 称 ,在 程序 运行 的 监控 界面 可 以 看 到 名 称 
def setAppName(name:String) :SparkConf = | 








set(" spark. app. name" ,name ) 





SparkContext 部 分 初始 化 关键 代码 如 下 。 
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// 构 造 参数 config 是 一 个 描述 了 Spark Application 配置 的 Spark 对 象 , 它 的 任何 设置 都 会 覆 
盖 默 认 配 置 和 System 属性 
class SparkContext( config :SparkConf) extends Logging with ExecutorAllocationClient | 


























// 当 通过 spark - submit 提交 Spark Application 时 ,加载 系统 属性 
def this( ) =this( new SparkConf( ) ) 


返回 SparkContext 配置 的 副本 ,这 个 配置 在 运行 时 不 能 被 更 改 
def SS =conf clone( ) 





//Spark 事件 的 异步 监听 bus 


private[ spark | val listenerBus = new LiveListenerBus 


// 初 始 化 SparkEnv 
privatel spark | def createSparkEnv( 
conf: SparkConf, 
isLocal : Boolean, 
listenerBus :LiveListenerBus ) :SparkEnv = | 
SparkEnv. createDriverEnv(conf ,isLocal ,listenerBus ,SparkContext. numDriverCores(master) ) 
| 


privatel spark | def env:SparkEnv = _env 


// 声 明 调 度 器 的 重要 组 件 SchedulerBackend 实例 对 象 变 量 
private| spark | def schedulerBackend :SchedulerBackend = _schedulerBackend 


| 
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private| spark | def schedulerBackend_ = (sb:SchedulerBackend) :Unit = | 
_schedulerBackend = sb 

| 

// 声 明 调度 器 的 重要 组 件 TaskScheduler 实例 对 象 变量 O) 

private| spark | def taskScheduler:TaskScheduler = _taskScheduler 

private| spark | def taskScheduler_= (ts:TaskScheduler) :Unit = | 
_taskScheduler = ts 

| 

// 声 明 调 度 器 的 重要 组 件 DAGScheduler 实例 对 象 变量 

private[ spark | def dagScheduler: DAGScheduler = _dagScheduler 

private| spark | def dagScheduler = (ds:DAGScheduler) :Unit = | 
_dagScheduler = ds 





// 根 据 Spark 的 不 同 部 署 模式 创建 相应 的 SchedulerBackend 和 TaskScheduler 实例 对 象 
val (sched,ts) = SparkContext. createTaskScheduler( this, master) 

_schedulerBackend = sched 

_taskScheduler = ts 

_dagScheduler = new DAGScheduler( this) 


// 在 TaskScheduler 设置 好 DAGScheduler 对 象 的 引用 后 ,启动 TaskScheduler 
_taskScheduler. start( ) 


//Spark Application 的 唯一 标识 ID ,例如 ; 

// -对 于 “本 地 ”Spark Application ,ID 格式 类 似 “local - 1433865536131? 

// -对 于 YARN”Spark Application ,ID 格式 类 似 “application_1433865536131_34483” 
def applicationld: String = _applicationld 

// 获 取 Spark Application 的 标识 思 

_applicationld = _taskScheduler. applicationId( ) 

// 初 始 化 BlockManager 


_env. blockManager. initialize( _applicationld ) 





SparkContext 实例 化 完毕 后 ， 就 可 以 调用 SparkContext 的 方法 来 实现 各 种 功能 了 。 下 面 
列 出 SparkContext 中 几 个 重要 或 常用 的 方法 ， 部 分 关键 代码 如 下 。 


A re 














// 根 据 给 定 的 master URL 创建 一 个 TaskScheduler 具体 实现 类 的 实例 对 象 
// 返 回 SchedulerBackend 和 TaskScheduler 具体 实现 类 的 实例 对 象 
private def createTaskScheduler( 
sc:SparkContext ， 
master:String) :(SchedulerBackend ,TaskScheduler) = | 
import SparkMasterRegex. _ 
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// 本 地 运行 失败 的 Task 不 会 被 重 试 
val MAX_LOCAL TASK_ FAILURES =1 


master match | 


// 从 一 个 本 地 Scala 集合 得 到 一 个 RDD 
def parallelize[ T. ClassTag | ( 
seq:Seq[ T]， 
numSlices: Int = defaultParallelism) :RDD[ T| = withScope | 
assertNotStopped ( ) 
new ParallelCollectionRDD| T |] (this, seq, numSlices, Map[ Immt,Seql String |] ] ( ) ) 


// 读 取 来 自 于 HDFS、 本 地 文件 系统 或 者 任意 一 个 Hadoop 支持 的 文件 系统 URI 的 文件 
// 返 回 一 个 由 String 的 字符 串 组 成 的 RDD 
def textFile( 
path :String， 
minPartitions : Int = defaultMinPartitions) :RDDL String | = withScope | 
assertNotStopped ( ) 
hadoopFile( path ,classOf[ TextInputFormat | , classOf[ LongWritable | , classOf[ Text | ， 
minPartitions ). map( pair => pair. _2. toString ) 


// 将 一 个 只 读 广播 变量 发 送 给 集群 中 的 每 个 结 点 
// 该 变量 只 给 集群 发 送 一 次 
def broadcast[ T:ClassTag | ( value:T) :Broadcast[ 了 了 ] = | 
assertNotStopped ( ) 
if (classOf[ RDD| _| ]. isAssignableFrom( classTag[Tj. runtimeClass) ) | 
// 用 警告 而 不 是 异常 是 为 了 避免 影响 用 户 程序 的 运行 
// 这 些 程序 可 能 创建 了 RDD 广播 变量 ,但 是 还 没有 使 用 它们 
logWarning( " Can not directly broadcast RDDs;instead ,call collect( )and " 
+" broadcast the result (see SPARK -5063)") 









































| 

val bc = env. broadcastManager. newBroadcast[| T | ( value, isLocal) 

val callSite = getCallSite 

logInfo( " Created broadcast " +bc. id+" from " +callSite. shortForm) 
cleaner. foreach( _. registerBroadcastForCleanup( bc ) ) 


be 





// 得 到 一 个 特定 RDD 的 partition 的 本 地 性 信息 
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private [ spark | def getPreferredLocs(rdd:RDD[ _| ,partition :Int) :Seq[ TaskLocation | = | 


dagScheduler. getPreferredLocs( rdd ,partition ) 








// 在 给 定 RDD 的 partitions 集合 上 运行 也 数 ,并 且 把 结果 传 给 指定 的 结果 处 理 函数 
口 





// 这 里 是 所 有 Spark Action 的 主人 








def runJob[ T,U .ClassTag | ( 


rdd:RDD[T], 
func: (TaskContext, Iterator[ T ] ) => U, 
partitions :Seq[ Int | ， 
resultHandler:(Int,U) => Unit) : Unit = | 
if (stopped. get( ) ) | 
throw new IllegalStateException( " SparkContext has been shutdown" ) 
| 
val callSite = getCallSite 
val cleanedFunc = clean( func) 
logInfo( " Starting job:" + callSite. shortForm ) 
if (conf getBoolean( " spark. logLineage" ,false) ) | 
logInfo(" RDD s recursive dependencies: \n" +rdd. toDebugString) 
| 
// 将 runJob 转交 给 DAGScheduler 去 完成 
dagScheduler. runJob( rdd ,cleanedFunc ,partitions ,callSite , resultHandler ,localProperties. get ) 
progressBar. foreach( _. finishAll( ) ) 
rdd. doCheckpoint( ) 


// 提 交 一 个 要 执行 的 Job, 并 且 将 返回 结果 放 在 一 个 FutureJob 对 象 中 
// 这 里 一 般 由 AsyncRDDAction 类 的 方法 调用 
def submitJob[ T,U,R]( 




















eT 


rdd:RDD[T], 

processPartition : Iterator| T |] => U, 

partitions :Seq[ Int | ， 

resultHandler: (Int,U) => Unit, 

resultFunc: => R) :SimpleFutureAction[ R] = 


assertNotStopped ( ) 
val cleanF = clean( processPartition ) 
val callSite = getCallSite 
val waiter = dagScheduler. submitJob( 
rdd ， 
(context :TaskContext ,iter:Iterator[ 了] ) => cleanF(iter) ， 


partitions ， 









内 核 机 制 解析 及 性 能 调 优 


91. callSite, 

92. resultHandler, 

93. localProperties. get) 

94. new SimpleFutureAction( waiter, resultFunc ) 
95. } 

96. 


Spark Job 的 触发 


Job 的 逻辑 执行 ( General Logical Plan ) 


典型 的 Job 逻辑 执行 图 如 下 图 4-3 所 示 ， 经 过 下 面 四 个 步骤 可 以 得 到 最 终 执行 结果 : 


数据 块 1 RDDI1 RDDi RDDm final RDD Results 


图 createRDDO 












transformation() shuffle transformation() action() 


© 


可 - 




















result of 


f) 








OOF 





图 4-3 Job 逻辑 执行 图 


1) 从 数据 源 (数据 源 可 以 是 本 地 File、 内 存 数据 结构 、HDFS、HBase 等 ) 读 取 数据 ， 
创建 最 初 的 RDD (createRDD() ) ; 

2) 对 RDD 进行 一 系列 的 transformation( ) 操 作 ， 每 一 个 transformation( ) 会 产生 一 个 或 
多 个 包含 不 同类 型 T 的 RDD[T]。T 可 以 是 Scala 里 面 的 基本 类 型 或 数据 结构 ， 不 限于 (K， 
V)。 但 如 果 是 (K,V) ，K 不 能 是 Array 等 复杂 类 型 (因为 难以 在 复杂 类 型 上 定义 partition 
函数 ); 

3) 对 最 后 的 final RDD 进行 action( ) 操作 ， 每 个 Partition 计算 后 产生 结果 Result。 

4) 将 Result 回 送 到 Driver 端 ， 进 行 最 后 的 f( list[ result] ) 计算 。 例 子 中 的 count( ) 实 
际 包含 了 action( ) 和 sum( ) 两 步 计算 。RDD 可 以 被 Cache 到 内 存 或 者 Checkpoint 到 磁盘 
上 。RDD 中 的 Partition 个 数 不 固 定 ， 通 常 由 用 户 设 定 。RDD 和 RDD 之 间 Partition 的 依赖 关 
系 可 以 不 是 1 对 1， 如 图 4-3 所 示 , 既 有 1 对 1 关系 ， 也 有 多 对 多 的 关系 。 
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Job 具体 的 物理 执行 








Spark Application 里 面 可 以 产生 1 个 或 者 多 个 Job， 例 如 spark - shell 默认 启动 的 时 候 内 > 
部 就 没有 Job， 只 是 作为 资源 的 分 配 程序 ， 可 以 在 spark - shell 里 面 写 代码 产生 若干 个 Job， 
普通 程序 中 一 般 而 言 可 以 有 不 同 的 Action， 每 一 个 Action 一 般 也 会 触发 一 个 Job。 

有 了 Job 的 逻辑 执行 图 ， 如 何 生成 物理 执行 图 ， 也 就 是 给 定 这 样 一 个 复杂 数据 依赖 图 ， 
如 何 合 理 划 分 Stage， 并 确定 Task 的 类 型 和 个 数 ? 

一 个 直观 的 方法 是 将 前 后 关联 的 RDD 组 成 一 个 Stage ， 每 个 Stage 生成 一 个 Task。 这 样 虽 
然 可 以 解决 问题 ,但 显然 效率 不 高 。 除 了 效率 问题 ， 这 个 方法 还 有 一 个 更 严重 的 问题 ， 大 量 中 
间 数 据 需 要 存储 。 对 于 Task 来 说 ， 其 执行 结果 要 么 要 存 到 磁盘 ， 要 么 存 到 内 存 ， 或 者 两 者 恬 
有 。 如 果 每 个 箭头 都 是 Task 的 话 ， 每 个 RDD 里 面 的 数据 都 需要 存 起 来 ， 占 用 空间 可 想 而 知 。 

仔细 观察 一 下 逻辑 执行 图 会 发 现 : 在 每 个 RDD 中 ， 每 个 Partition 是 独立 的 ， 也 就 是 说 
在 RDD 内 部 ， 每 个 Partition 的 数据 依赖 各 自 不 会 相互 干扰 。 因 此 ,一 个 大 胆 的 想法 是 将 整 
个 流程 图 看 成 一 个 Stage, 为 最 后 一 个 finalRDD 中 的 每 个 Partition 分 配 一 个 Task。 即 Pipeline 
思想 : 数据 用 的 时 候 再 算 ， 而 且 数 据 是 流 到 要 计算 的 位 置 的 。 

Spark 算法 构造 和 物理 执行 时 最 最 基本 的 核心 : 最 大 化 Pipeline! 基于 Pipeline 的 思想 ， 
数据 被 使 用 的 时 候 才 开始 计算 ， 从 数据 流动 的 视角 来 说 ， 是 数据 流动 到 计算 的 位 置 。 实 质 上 
从 逻辑 的 角度 来 看 ， 是 算 子 在 数据 上 流动 ! 从 算法 构建 的 角度 而 言 : 肯定 是 算 子 作用 于 数 
据 ， 所 以 是 算 子 在 数据 上 流动 ; 方便 算法 的 构建 ! 

从 Job 物理 执行 的 角度 而 言 : 是 数据 流动 到 计算 的 位 置 ， 方 便 系统 最 为 高 效 的 运行 。 对 
于 Pipeline 而 言 ， 数 据 计 算 的 位 置 就 是 每 个 Stage 中 最 后 的 RDD。 也 就 是 说 ， 每 个 Stage 中 除 
了 最 后 一 个 RDD 算 子 是 真实 的 以 外 ， 前 面 的 算 子 都 是 “ 假 ”的 ! 由 于 计算 的 Lazy 特性 ， 计 
算是 从 后 往 前 回 湖 ， 形 成 Computing Chain ， 结 果 需 要 首先 计算 出 具体 一 个 Stage 内 部 左 侧 的 
RDD 中 本 次 计算 依赖 的 Partition。 如 图 4-4 所 示 : 















































RDD 算 子 计 算 : 
。 图 中 三 个 Stage:Stagel、Stage2、Stage3 
。 Stage3 内 部 左 侧 B 的 计算 依赖 于 G 的 Partition, 
如 G 为 3 个 Partition, 那 就 有 3 个 并 行 Task, 从 后 往 前 
回调 ，B 也 是 3 个 Partition, 3 个 Task。 
。 Stagel 内 部 A 设置 3 个 Partition, 与 Stage3 的 B 进 行 
groupBy 操作 。 
。 Stage2 内 部 左 侧 C、D、F、 左 侧 C 的 计算 依赖 于 F 
Partition，F 设 置 2 个 Partition, 2 个 Task 并 行 计算 ， 
从 后 往 前 回 滴 ， 推 出 C、D、F 也 是 2 个 Task, C、D、 
F 形 成 了 map 的 Pipeline: 上 设置 2 个 Partition, 与 E 是 2 
个 Task 并 行 计算 : 将 C、D 与 E 的 计算 结果 进行 Union 
。 Stage 2F 计 算 的 结果 再 与 Stage 3 的 B 进 行 Join 。 





| 


























图 4-4 RDD 算 子 计算 过 程 





总 结 一 下 这 个 过 程 : 整个 Computing Chain 根据 数据 依赖 关系 自 后 向 前 建立 ， 遇 到 Shuf- 
fleDependency 后 形成 Stage。 在 每 个 Stage 中 ， 每 个 RDD 中 的 compute( ) 调 用 parentRDD. iter( ) 
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来 将 parent RDD 中 的 Record 一 个 个 “ 拿 ”(fetch) 过 来 。 

例如 ，collect 前 面 的 RDD 是 transformation 级 别 的 ， 不 会 立即 执行 。 从 后 往 前 推 ， 回 济 
时 如 果 是 窄 依 赖 则 在 内 存 中 迭代 ， 否 则 把 中 间 结 果 写 出 到 磁盘 暂 存 给 后 面 的 计算 使 用 。 

依赖 分 为 罕 依 赖 和 宽 依 赖 。 例 如 现实 生活 中 ， 工 作 依赖 一 个 对 象 ， 是 窄 依赖 依赖 很 多 
对 象 ， 是 宽 依赖 。 罕 依赖 除了 一 对 一 外 ， 还 有 range 级 别 的 依赖 ， 依 赖 固定 的 个 数 ， 随 着 数 
据 的 规模 扩大 而 改变 。 

如 果 是 宽 依 赖 ，DAGScheduler 会 划分 成 不 同 的 stage ，stage 内 部 是 基于 内 存 迭 代 的 ， 也 
可 以 基于 磁盘 迭代 ，stage 内 部 计算 的 逻辑 是 完全 一 样 的 ， 只 是 计算 的 数据 不 同 而 已 。 具 体 
的 任务 就 是 计算 一 个 数据 分 片 ， 一 个 partition 的 大 小 是 128Mb。 一 个 partition 不 是 完全 精准 
的 等 于 一 个 block 的 大 小 ， 一 般 最 后 一 条 记录 跨 两 个 block。 

如 图 4-5 所 示 ， 因 为 reduceByKey 会 产生 shuffle (〈 宽 依赖 ) ， 所 以 这 里 有 两 个 Stage。 
为 collect 操作 是 一 个 aetion， 所 以 会 触发 Job。 从 后 往 前 推 ， 每 个 stage 内 部 都 有 一 系列 的 任 
务 ， 下 面 来 看 第 一 个 Stage。Stage 0 内 部 的 textFile 、flatMap 、map 默认 基于 内 存 迭 代 ， 如 果 
内 存 不 够 会 基于 磁盘 迭代 。 


> 
DD Wow, My First Spark App! X WN 
€ GC | D 192. 168. 189. 1:1 istor -20161129194550-001 s id= hd 











Jobs | Stages Storage Environment Executors Wow,My First Spark App! application U 
QAMK 161 


Details for Job 0 


Status: SUCCEEDED 
Completed Stages: 2 








Completed Stages (2) 


Stage Tasks: Shuffle Shuffle 
ld Description Submitted Duration Succeeded/Total Input Output Read Write 
4 ollect at WordCount.scala:74 +details 2016/11/29 6s 88/88 692.8 KB 

19:46:13 


0 map at WordCount.scala:61 +details 2016/11/29 8s 88/88 288.7 1064.4 KB 
19:46:04 KB 


图 4-5 Job 0 的 所 有 Stage 视图 


如 图 4-6 所 示 ，Stage 0 总 共有 88 个 任务 ， 图 中 方 框 内 清楚 地 告诉 用 于 运行 了 哪些 代码 。 
在 具体 运行 时 ，stage 内 部 没有 SparkContext 和 SparkConf。 因 为 它们 属于 核心 Driver 层面 。 

如 图 4-7 所 示 ， 任 务 都 是 运行 在 Executor 中 。 默 认 每 台 机 器 为 当前 的 程序 分 配 一 个 Ex- 
ecutor， 这 里 有 4 个 Worker， 所 以 有 4 个 Executor。 可 以 看 到 每 个 Executor 上 的 任务 运行 情 
况 。Worker 本 身 就 是 管理 Executor 的 。 
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口 Wow, My First Spark Appl xX WN 
€ 3 CC D192.168.189.1:18080/history/app-2016112 





9194550-0013/stages/stage/?id=0&attempt=0 kd 





Details for Stage 0 (Attempt 0) 


Total Time Across All Tasks: 35 S 
Locality Level Summary: Node local: 88 
Input Size /| Records: 288.7 KB / 8360 
Shuffle Write: 1064.4 KB / 22880 


Spa 161 Jobs Stages Storage Environment Executors Wow,My First Spark App! application UI | 





v DAG Visualization 


Sstage 0 
textFile 


hdfsmaster.9000/inputidata/ [0] 
textFile at WordCount scala:49 


| 


hdfs:master.9000/inputidata/ [1] 
textFile at WordCountscala:49 


fatMap 


MapParttionsRDD [2] 
flatMap at WordCount.scala:55 


map 


MapPartitionsRDD [3] 
map at WordCountscala:61 


Show Additional Metrics 
» Event Timeline 


Summary Metrics for 88 Completed Tasks 


Metric Min 25th percentile Median 75th percentile Max 
Duration 69ms 0.1s 0.2S 0.3S 3S 
GC Time 0 ms 0 ms 0 ms 0 ms 0.3S 


Input Size/ Records 3.3 KB/95 3.3 KB/95 3.3 KB/95 3.3 KB/95 3.3 KB/95 
地 
4-6 Stage 0 视图 


Aggregated Metrics by Executor 


ExecutorID“^ Address Task Time Total Tasks Failed Tasks Succeeded Tasks Input Size / Records Shuffle Write Size /| Records 
0 worker5:47450 9s 11 0 11 36.1 KB/1045 133.1 KB/2860 

| worker8:51101 8s 11 0 11 36.1 KB/ 1045 133.1 KB/2860 

2 worker6:32976 8s 7 0 7 23.0 KB /665 84.7 KB/ 1820 

3 worker4:36721 8s 12 0 12 39.4 KB/1140 145.1 KB/3120 


图 4-7 Worker 中 的 Executor 级 别 的 任务 运行 视图 


如 图 4-8 所 示 ，Tasks 运行 在 不 同 的 机 器 上 。 

Spark 程序 的 运行 有 两 种 部 署 方式 : Client 和 Cluster。 

默认 情况 下 建议 使 用 Client 模式 ， 此 模式 下 可 以 看 到 更 多 的 交互 性 信息 及 运行 过 程 的 信 
息 。 此 时 要 专门 使 用 一 台 机 需 来 提交 Spark 程序 ， 配 置 和 普通 的 Worker 2 而 且 要 
和 Cluster Manager 在 同样 的 网 络 环境 中 ， 因 为 要 指挥 所 有 的 Worker 去 工作 ，Worker 里 的 线 
程 要 和 Driver 不 断 地 交互 。 由 于 Driver 要 驱动 整个 集群 ， 频 繁 地 与 所 有 为 当前 程序 分 配 的 
Executor 去 交互 ， 频 繁 地 进行 网 络 通信 ， 所 以 必须 在 同样 的 网 络 中 。 

也 可 以 指定 部 署 方式 为 Cluster， 这 样 Driver 会 由 Master 决定 在 Worker 中 的 某 一 台 机 央 。 
Master 为 用 户 分 配 的 第 一 个 Executor 就 是 Driver 级 别 的 Executor。 不 推荐 学 习 和 开发 时 使 用 
Cluster， 因 为 Cluster 无 法 直接 看 到 一 些 日 志 信息 ， 所 以 建议 使 用 Client 方式 。 
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Tasks 
Index Locality Executor ID/ cc Input Size/ Write Shuffle Write Size / 
用 ID Attempt Status Level Host Launch Time Duration Time Records Time Records Errors 
0 2 |o SUCCESS NODE_LOCAL 5/worker2 2016/11/29 3s 02s 3.3KB(hadoop)/95 13 ms 12.1 KB /260 
19:46:05 
1 1 0 SUCCESS NODE_LOCAL 1/worker8 2016/11/29 2s 0.1sS 3.3 KB (hadoop)195 24 ms 12.1 KB /260 
19:46:05 
这 3 0 SUCCESS NODE_LOCAL 了 /1worker1 2016/11/29 3S 0.1s 3.3 KB (hadoop)195 13 ms 12.1 KB /260 
19:46:05 
3 5 0 SUCCESS NODE_LOCAL 2/worker6 2016/11/29 3s 03s 3.3KB(hadoop)/95 38 ms 12.1 KB /260 
19:46:05 
4 6 0 SUCCESS NODE_LOCAL 4/worker3 2016/11/29 2s 01s 3.3KB(hadoop)/95 6ms 12.1 KB /260 
19:46:05 
5 0 0 SUCCESS NODE_LOCAL 071worker5 2016/11/29 2s 01s 3.3KB(hadoop)/95 11ms 12.1 KB /260 
19:46:04 
6 vr SUCCESS NODE_LOCAL 3/worker4 2016/11/29 2s O01s 3.3 KB (hadoop)195 13 ms 12.1 KB /260 
19:46:05 
二 8 0 SUCCESS NODE_LOCAL 3/worker4 2016/11/29 03s 3.3 KB (hadoop)195 21ms 12.1 KB /260 
19:46:10 
8 10 0 SUCCESS NODE_LOCAL 4/worker3 2016/11/29 03s 3.3 KB (hadoop)195 6 ms 12.1KB1260 
19:46:10 
9 4 0 SUCCESS NODE_LOCAL 6/worker7 2016/11/29 2s 01s 3.3KB(hadoop)/95 11 ms 12.1 KB /260 
19:46:05 
10 9 0 SUCCESS NODE_LOCAL 0/worker5 2016/11/29 03s 3.3 KB (hadoop)195 3 ms 12.1 KB /260 
19:46:10 
11 11 0 SUCCESS NODE_LOCAL 1/worker8 2016/11/29 02s 3.3 KB (hadoop)195 5ms 12.1 KB /260 
19:46:10 
12 14 0 SUCCESS NODE_LOCAL 7/worker1 2016/11/29 02s 3.3 KB (hadoop)195 7 ms 12.1KB1260 
19:46:11 
13 15 0 SUCCESS NODE_LOCAL 0/worker5 2016/11/29 03s 3.3 KB (hadoop)195 12 ms 12.1 KB / 260 
19:46:11 
14 13 0 SUCCESS NODE_LOCAL 3/worker4 2016/11/29 02s 3.3 KB (hadoop)195 13 ms 12.1 KB /260 
19:46:11 
全 16_n SuceEss NAONF LOCAL | 4 /wnrkera 2046141/99 nas 2 akR (hadnan\ /95 | 2 me 42 4.KR 1 IEN 





吏 








4-8 ”Task 级 别 的 运行 视图 








2 Job 触发 流程 源 代 码 解析 


对 于 Spark Job 触发 流程 的 源 代 码 ， 下 面 以 RDD 的 count( ) 为 例 来 讲解 。RDD 的 count 
方法 代码 如 下 。 





人 /水 水 
* 返回 RDD 中 元 素 的 数量 
*/ 
def count( ) :Long = sc. runJob( this, Utils. getlteratorSize _). sum 


从 上 面 的 代码 可 以 看 出 ，count 方法 触发 SparkContext 的 runJob 方法 的 调用 。SparkCon- 
text 的 runjob 方法 代码 如 下 。 


er 


人 /沙洲 
* 触发 一 个 Job 处理 一 个 RDD 的 所 有 partitions ,并 且 把 处 理 结 果 返 回 到 一 个 数组 
*/ 

def runJob| T,U:ClassTag | (rdd:RDDI T] ,func:Iterator[ T|] =>U):Array[ U|] = | 
runJob( rdd ,func ,0 until rdd. partitions. length ) 


A dr 


| 
进入 SparkContext 的 runJob 方法 的 同名 重 载 方法 ， 该 方法 的 代码 如 下 。 


这 紧 器 
* 触发 一 个 Job 处 理 一 个 RDD 的 指定 部 分 的 partitions, 并且 把 处 理 结果 返回 到 一 个 数组 。 
* 比 第 一 个 runJob 方法 多 了 一 个 partitions 数组 参数 
S37 


-ee 
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def runJob[ T,U:ClassTag | ( 
rdd:RDD[ T], 
func: Tterator| T | => U, 
partitions:Seq[ Int | ) :Array[ U] = | O) 
val cleanedFunc = clean( func) 
runJob( rdd, (ctx:TaskContext,it: Iterator[ T ] ) => cleanedFunc(it) ,partitions) 


| 


再 进入 SparkContext 的 runJob 方法 的 另 一 个 同名 重 载 方 法 ， 该 方法 的 代码 如 下 。 


EL 


S 


11. 
jp 


最 后 一 次 





OEE I A eS rl 


和 
i 





/#¥* 
* 触发 一 个 Job 处 理 一 个 RDD 的 指定 部 分 的 partitions, 并 且 把 处 理 结 果 返 回 到 一 个 数组 
* 比 第 一 个 runJob 方法 多 了 一 个 partitions 数组 参数 ,并 且 func 的 类 型 不 同 
*/ 
def runJob[T,U:ClassTag]( 
rdd:RDD[T], 
func: (TaskContext, Iterator[ T | ) => U, 
partitions:Seq[ Int | ) :Array[ U] = | 

















val results = new Array[ U | ( partitions. size ) 
runJob[ T,U |] (rdd,func ,partitions, (index, res) => results( index) = res) 


results 


| 


进入 SparkContext 的 runJob 方法 的 另 一 个 同名 重 载 方 法 ， 该 方法 的 代码 如 下 。 





/kk 
* 触发 一 个 Job 处 理 一 个 RDD 的 指定 部 分 的 partitions ,并 把 处 理 结果 给 指定 的 handler 艺 数 
* 这 是 Spark 所 有 Action 的 主人 口 
*/ 
def runJob[T,U:ClassTag]( 
rdd:RDD[T], 
func: (TaskContext, Iterator[ T | ) => U, 








partitions :Seq[ Int ] ， 
resultHandler: (Int,U) => Unit) :Unit = | 
if (stopped. get( ) )| 
throw new IllegalStateException( "SparkContext has been shutdown" ) 
| 
// 记 录 了 方法 调用 的 方法 栈 
val callSite = getCallSite 
// 清 除 闭 包 , 为 了 函数 能 够 序列 化 
val cleanedFunc = clean( func) 
logInfo( " Starting Job:" + callSite. shortForm) 
if (conf. getBoolean( "spark. logLineage" ,false) ) | 
logInfo( " RDD s recursive dependencies: \n" + rdd. toDebugString) 
| 
// 问 高 层 调度 器 (DAGScheduler) 提交 Job ,从 而 获得 Job 执行 结 曙 





pa 












内 核 机 制 解析 及 性 能 调 优 


已 2 dagScheduler. runJob( rdd ,cleanedFunc ,partitions ,callSite ,resultHandler,localProperties. get) 
2 progressBar. foreach( _. finishAll( ) ) 

24. rdd. doCheckpoint( ) 

25 0 


关于 高 层 调度 器 (DAGScheduler) 的 原理 和 源 代 码 解析 将 在 下 面 的 章节 中 详细 讲解 。 








高 层 的 DAG 调度 器 ( DAGScheduler) 


医 区 DAG 的 定义 ) 


在 2.2 节 中 介绍 了 RDD DAG 构建 了 RDD 的 数据 流 ， 即 RDD 的 各 个 分 区 的 数据 是 从 哪 
来 的 ; 还 进一步 分 析 了 RDD DAG 的 生成 机 制 和 RDD DAG 的 逻辑 视图 。 

RDD DAG 还 构建 了 基于 数据 流 之 上 的 操作 算 子 流 ， 即 RDD 的 各 个 分 区 的 数据 总 共 会 经 
过 哪些 Transformation 和 Action 这 两 种 类 型 的 一 系列 操作 的 调度 运行 ， 从 而 RDD 先 被 Trans- 
formation 操作 转换 为 新 的 RDD， 然 后 被 Action 操作 将 结果 反馈 到 Driver Program 或 存储 到 外 
部 存储 系统 上 。 

上 面 提 到 的 一 系列 操作 的 调度 运行 其 实 是 DAG 提交 给 DAGScheduler 来 解析 完成 的 。 
DAGScheduler 是 面向 Stage 的 高 层级 的 调度 器 ，DAGScheduler 把 DAG 拆 分 成 很 多 Tasks ， 
组 Tasks 都 是 一 个 Stage， 解 析 时 是 以 Shuffle 为 边界 反 向 解析 构建 Stage (参考 4.4.3 节 和 
4.4.4 节 )， 每 当 遇 到 Shuffle 就 会 产生 新 的 Stage， 然 后 以 一 个 个 TaskSet (每 个 Stage 封装 一 
个 TaskSet) 的 形式 提交 给 底层 调度 器 TaskScheduler (参考 4.5 节 ) 。 另 外 ，DAGScheduler 需 
要 记录 哪些 RDD 被 存 人 磁盘 等 物化 动作 ， 同 时 要 寻求 Task 的 最 优化 调度 ， 如 在 Stage 内 部 数 
据 的 本 地 性 等 (参考 4.4.5 节 ) 。DAGScheduler 还 需要 监视 因为 Shuffle 跨 结 点 输出 可 能 导致 的 
失败 ， 如 果 发 现 这 个 Stage 失败 ， 可 能 就 要 重新 提交 该 Stage (参考 5.3.3 节 的 相关 内 容 ) 。 

由 此 可 见 ， 为 了 更 好 地 理解 Spark 高 层 调度 器 DACScheduler， 除 了 已 经 提 到 过 的 RDD ( 参 
考 1.2.1 节 的 相关 内 容 ) 、Application (参考 3.2 节 的 相关 内 容 ) 、Driver Program (人 参考 4.2.1 
节 的 相关 内 容 ) 和 Job (参考 4.3 节 的 相关 内 容 ) 这 些 概念 以 外 ， 还 需要 了 解 以 下 几 个 概念 。 

1) Stage: 一 个 Job 需要 拆 分 成 多 组 任务 来 完成 ， 每 组 任务 由 Stage 封装 。 跟 一 个 Job 的 
所 有 涉及 的 PartitionRDD 类 似 ，Stage 之 间 也 有 依赖 关系 。 

2) TaskSet: 一 组 任务 就 是 一 个 TaskSet， 对 应 一 个 Stage。 其 中 ， 一 个 TaskSet 的 所 有 
Task 之 间 没 有 Shuffle 依赖 ， 因 此 互相 之 间 可 以 并 行 运行 。 

3) Task: 一 个 独立 的 工作 单元 ， 由 Driver Program 发 送 到 Executor (参阅 第 5 章 ) 上 去 
执行 。 通 常情 况 下 ， 一 个 Task 处 理 RDD 的 一 个 Partition 的 数据 。 根 据 Task 返回 类 型 的 不 
同 ，Task 又 分 为 ShuffleMapTask 和 ResultTask 。 


4.4.2 DAG 的 实例 化 


在 Spark 源 代 码 中 ，DAGScheduler 是 在 整个 Spark Application 的 入 口 即 SparkContext 中 声 
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明 并 实例 化 的 。 在 实例 化 DAGScheduler 之 前 ， 已 经 实例 化 了 SchedulerBackend 和 底层 调度 需 
TaskScheduler， 而 SchedulerBackend 和 TaskScheduler 是 通过 SparkContaxt 的 方法 createTask- 
Scheduler 实例 化 的 。DAGScheduler 在 提交 TaskSet 给 底层 调度 器 时 是 面向 TaskScheduler 接口 
的 ， 这 符合 面向 对 象 中 依赖 抽象 而 不 依赖 具体 实现 的 原则 ， 带 来 底层 资源 调度 器 的 可 插 拔 
性 ， 使 得 Spark 可 以 运行 在 众多 的 资源 部 署 模式 上 ， 例 如 Standalone、YARN 、Mesos 、Local， 
以 及 其 他 自 定 义 的 布 署 模 式 。 

SparkContext 源 代码 中 相关 的 代码 如 下 。 

















I 

2 @ volatile private var _dagScheduler: DAGScheduler=_ 

3 

4. 

5. private| spark| def dagScheduler:DAGScheduler =_dagScheduler 
private| spark | def dagScheduler_= (ds:DAGScheduler) :Unit = | 

_dagScheduler = ds 

| 

6. 


8. val (sched,ts) = SparkContext createTaskScheduler(this ,master) 
_schedulerBackend = sched 
_taskScheduler = ts 


10. // 实 例 化 DAGScheduler 时 传人 当前 的 SparkContext 实例 化 对 象 
11l. _dagScheduler = new DAGScheduler( this) 





13. /启动 TaskScheduler 实例 对 象 ,等 待 DAGScheduler 提交 TaskSet 给 TaskScheduler 
14. _taskScheduler. start( ) 


DAGScheduler 源 代码 中 相关 的 代码 如 下 。 


private| spark ] 

class DAGScheduler( 
private| scheduler | val sc:SparkContext, 
private| scheduler | val taskScheduler: TaskScheduler, 
listenerBus : LiveListenerBus, 
mapOutputTracker:MapOutputTrackerMaster， 
blockManagerMaster: BlockManagerMaster， 
env:SparkEnv ， 
clock :Clock = new SystemClock( ) ) 

extends Logging | 


pl A Br Se 


2 


[2 def this( sc :SparkContext,taskScheduler: TaskScheduler) = | 
13. this( 
14. SC， 








© 









内 核 机 制 解析 及 性 能 调 优 


13; taskScheduler ,16. sc. listenerBus, 

17. sc. env. mapOutputTracker. asInstanceOf[ MapOutputTrackerMaster | ， 
18. sc. env. blockManager. master， 

19. sc. env) 

20. } 

Zi 


2 //SparkContext 实例 化 DAGScheduler 的 入 口 ,利用 传人 的 SparkContext 实例 对 象 来 设 
2 // 置 将 要 提交 TaskSet 的 TaskScheduler 实例 对 象 的 引用 
24. def this(sc:SparkContext) =this(sc,sc. taskScheduler) 


26. //TaskScheduler 实例 对 象 也 要 设置 提交 给 它 的 TaskSet 的 DAGScheduler 实例 对 象 的 引用 
2 taskScheduler. setDAGScheduler( this) 





























DAGScheduer 划分 Stage 的 原理 了 





Spark 在 分 布 式 环境 下 将 数据 分 区 ， 然 后 将 作业 转化 为 DAG， 并 分 阶段 进行 DAG 的 调 
度 和 任务 的 分 布 式 并 行 处 理 。DAG 将 调度 提交 给 DAGScheduler，DAGScheduler 调度 时 会 根 
据 是 否 需 要 经 过 Shuffle (具体 的 Shuffle 运行 机 制 参考 第 7 章 ) 过 程 将 Job 划分 为 多 个 Stage。 

为 了 方便 理解 DAGScheduler 划分 Stage 的 原理 ， 下 面 来 回顾 一 下 2. 2 市 中 的 一 个 典型 的 
DAG 划分 Stage 示意 图 ， 如 图 4-9 所 示 。 

















人 = Stage 3 
Ek 





图 4-9 DAG 划分 Stage 及 Stage 并 行 计算 示意 图 


其 中 ， 实 线 圆 角 方 框 标识 的 是 RDD， 方 框 中 的 矩形 块 为 RDD 的 分 区 。 

在 图 4-9 中 ，RDD A 到 RDD B 之 间 ， 以 及 RDD 下 到 RDD G 之 间 的 数据 需要 经 过 Shuf- 
fle 过 程 ， 因 此 RDD A 和 RDD 下 分 别 是 Stage 1 跟 Stage 3 和 Stage 2 跟 Stage 3 的 划分 点 。 而 
RDD B 到 RDD G 之 间 , 以 及 RDD C 到 RDD D 到 RDDF 和 RDDE 到 RDDF 之 间 的 数据 不 
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需要 经 过 Shuffle 过 程 ， 因 此 ，RDD G 和 RDD B 的 依赖 是 窜 依 赖 ，RDD B 和 RDD G 划分 到 
同一 个 Stage 3，RDD F 和 RDD D 加 RDD EE 的 依赖 ， 以 及 RDD D 和 RDD C 的 依赖 是 窄 依赖 ， 
RDD C、RDD D、RDD E 和 RDD 下 划分 到 同一 个 Stage 2。Stage 1 和 Stage 2 是 相互 独立 的 ， 可 
以 并 发 执行 。 而 由 于 Stage 3 依赖 Stage 1 和 Stage 2 的 计算 结果 ， 所 以 Stage 3 最 后 执行 计算 。 

根据 以 上 RDD 依赖 关系 的 描述 ， 在 图 4-9 中 的 操作 算 子 中 ，map 和 union 是 窄 依赖 的 
操作 ， 因 为 子 RDD (如 D) 的 分 区 只 依赖 父 RDD (如 C) 的 一 个 分 区 ， 其 他 常见 的 罕 依 赖 
的 操作 还 有 fter 、flatMap 和 join (每 个 分 区 和 已 知 的 分 区 join) 等 。groupByKey 和 join 是 宽 
依赖 操作 ， 其 他 常见 的 宽 依赖 操作 还 有 reduceByKey 等 。 

由 此 可 见 ， 在 DAGScheduler 的 调度 过 程 中 ，Stage 阶段 的 划分 是 根据 是 否 有 Shuffle 过 
程 ， 也 就 是 当 存 在 ShuffleDependency 的 宽 依 赖 时 ， 需 要 进行 Shuffle， 此 时 才 会 将 作业 (Job) 


划分 成 多 个 Stage。 





























| DAGSeheduer 划分 Stage 的 具体 算法 汪 


有 _ Sg 


理解 了 前 面 DAGScheduler 划分 Stage 的 原理 后 ， 现 在 结合 Spark 源 代码 来 看 看 Spark 是 
如 何 实现 DAGScheduler 划分 Stage 算法 的 。 

RDD 的 Action 操作 算 子 如 count 会 触发 一 个 Spark Job ， 其 实 是 RDD 的 count 方法 调用 了 
SparkContext 的 runjJob 方法 。 然 后 ， 在 SparkContext 的 runjob 方法 中 调用 3 次 重 载 的 runJob 
方法 。 最 后 被 调用 的 重 载 runjob 方法 中 调用 了 DAGScheduler 的 runJob 方法 ， 从 而 进入 DAG- 
Scheduler 的 源 代码 。 

在 DAGScheduler 的 源 代码 中 ，DAGScheduler 的 runJob 方法 中 调用 submitJob 方法 。sub- 
mitjob 方法 中 最 重要 的 是 创建 一 个 JopWaiter 对 象 ， 以 及 创建 JobSubmitted 事件 对 象 把 Job- 
Waiter 对 象 发 送 给 DAGScheduler 的 内 髓 类 DAGSchedulerEventProcessLoop 对 象 实 例 。DAG- 
SchedulerEventProcessLoop 在 doOnReceive 方法 中 反 过 来 调用 了 DAGScheduler 中 实现 划分 
Stage 算法 很 关键 的 handleJobSubmitted 方法 。 

DAGScheduler 的 handleJobSubmitted 方法 中 调用 newResultStage 方法 ，newResultStage 方 
法 根据 finalRDD 创建 finalStage， 这 时 便 真 正 开 始 了 Stage 的 划分 。DAGScheduler 的 handle- 
JobSubmitted 方法 中 最 后 调用 submitStage 方法 ， 根 据 RDD 的 依赖 关系 ,递归 提交 所 有 的 
Stageo 

DAGScheduler 的 handleJobSubmitted 方法 关键 的 代码 如 下 。 






































private|l scheduler | def handleJobSubmitted( jobId : Int ， 
finalRDD:RDDL_ |] ， 
func: (TaskContext, Iterator[ _ | ) => _， 
partitions : Array[ Int | ， 
callSite:CallSite ， 
listener:JobListener， 
properties : Properties ) | 


var finalStage:ResultStage = null 


A Ne se 


try | 
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10. // 新 Stage 的 创建 过 程 中 可 能 会 抛 出 异常 ,例如 :job 运行 在 HadoopRDD 之 上 ,而 Hadoop 
底层 的 HDFS 文件 已 经 被 删除 了 ,就 会 抛 出 异常 

11. // 以 finalRDD 为 基础 ,开始 整个 Job 的 Stage 划分 

12. finalStage = newResultStage( final RDD , func , partitions , jobld , callSite ) 

下 5 | catch | 

14. 

ee 

16. 

LA 





18. // 从 finalStage 开始 ,根据 RDD 的 依赖 关系 ,递归 提交 所 有 的 Stage 
19. submitStage( finalStage ) 


Dl 


DAGScheduler 的 newResultStage 方法 中 调用 getParentStagesAndId 方法 得 到 ResultStage 所 
有 依赖 的 Parent Stage 列表 ， 以 及 ResultStage 的 Stage ID。 
DAGScheduler 的 newResultStage 方法 的 代码 如 下 。 


1 private def newResultStage( 

多 rdd:RDD|[ _]， 

3 func: (TaskContext, Iterator[ _ | ) => _， 

4 partitions: Array[ Int | ， 

Sa jobld ; Int, 

6 callSite: CallSite ) :ResultStage = | 

7 // 根 据 当 前 的 RDD 和 Job ID 得 到 所 有 依赖 的 Parent Stage 列表 ,以 及 ResultStage ID 
8 val (parentStages:List[ Stage | ,id :Int) = getParentStagesAndId( rdd , jobld) 

9 // 创 建 ResultStage 对 象 实例 

10. val stage = new ResultStage( id,rdd,func ,partitions ,parentStages ,jobId,callSite ) 





11. stageldToStage( id) = stage 

12. updateJobldStageldMaps( jobId , stage ) 
13. stage 

14. | 





DAGScheduler 的 getParentStagesAndId 方法 比较 简单 ， 主 要 是 调用 getParentStages 方法 ， 
其 他 就 是 得 到 一 个 当前 最 大 的 Stage ID。 
DAGScheduler 的 getParentStagesAndld 方法 的 代码 如 下 。 





private def getParentStagesAndId( rdd: RDD!| _| ,firstJobld: Int) :(Listl Stage | ,It) = | 
val parentStages = getParentStages( rdd ,firstJobld ) 
val id = nextStageld. getAndIncrement( ) 
(parentStages ,id ) 


NT 








第 4 章 Spark 调 度 器 (Scheduler ) 运行 机 制 








可 以 说 ，DAGScheduler 的 getParentStages 方法 是 划分 Stage 的 核心 实现 。 这 个 方法 的 
输出 是 获取 或 创建 给 定 的 RDD 在 Job 中 的 所 有 Parent Stage 列表 。 在 该 方法 中 ，Stage 的 划 
分 由 最 后 一 个 Result Stage 开始 ， 从 后 往 前 回溯 边 划 分 边 创 建 。 给 定 的 RDD 会 先 被 压 入 
Stack ， 以 便 被 逐个 访问 。 对 每 个 被 访问 的 RDD， 判 断 其 Dependeney 是 否 是 ShuffleDepen- 
dency 宽 依 赖 : 如 果 是 ， 就 调用 getShuffleMapStage 方法 获取 或 创建 Stage， 并 放 到 一 个 临时 
HashSet 中 ， 便 于 统一 最 后 转 为 列表 返回 ， 如果 不是 ， 就 把 Dependency 的 RDD 也 压 入 
Stack 中 ， 继 续 判 断 该 RDD 的 Dependency。 方法 的 结束 标志 是 Stack 中 所 有 压 入 的 临时 
RDD 都 被 访问 过 。 

DAGScheduler 的 getParentStages 方法 的 代码 如 下 。 









































1 private def getParentStages( rdd: RDD| _| ,firstJobld :Int) :Listl Stage] = | 

2 val parents = new HashSet| Stage | 

3 val visited =new HashSet[ RDD[_]] /存储 已 经 被 访问 的 RDD ,构建 时 是 从 后 往 前 回溯 的 
4 /7 维护 一 个 栈 ,防止 由 于 递归 访问 引起 的 栈道 出 异常 (StackOverflowError) 

SS val waitingForVisit = new Stack[ RDD[_] ] /存储 需要 被 处 理 的 RDD 
6 

% 

8 

9 








def visit(r:RDD[ _])!| 
if (lvisited(r))| 
visited +=r// 如 果 RDD 没 被 访问 过 ,那么 这 次 就 将 此 RDD 加 入 访问 过 的 RDD HashSet 中 
// 由 于 Partition 未 知 ,所 以 需要 注册 RDD 














10. for (dep <- dependencies ) | 

11. dep match | 

i //RDD 的 依赖 是 ShuffleDependency 宽 依 赖 ,获取 或 创建 新 Stage 
3 case shufDep: ShuffleDependency[ _,_,_| => 

14. parents += getShuffleMapStage( shufDep ,firstJobId ) 

1Ss //RDD 的 依赖 不 是 ShuffleDependency 宽 依赖 ,把 依赖 的 RDD 压 入 待 访问 RDD 的 Stack 中 
16. case _ => 

a waitingForVisit. push( dep. rdd) 

18. | 

19. } 

20. } 

2 } 


22. ”// 先 压 入 给 定 的 RDD 到 待 访问 Stack 中 
23. waitingForVisit. push( rdd) 
24. while (waitingForVisit. nonEmpty) | A/ 如 果 Stack 不 为 空 ,继续 访问 Stack 的 下 一 个 RDD 





23: visit( waitingForVisit. pop( ) ) 
26. } 

2 parents. toList 

2800 


剩 下 的 过 程 就 比较 容易 理解 了 ，DAGScheduler 的 getShuffleMapStage 方法 先 根据 给 定 的 
ShuffleDependency 的 shuffleld 在 shuffleToMapStage 这 个 HaskMap 中 获取 相应 的 ShuffleMap- 
Stage ， 若 没有 找到 ， 就 创建 一 个 新 的 Stage 返回 。 
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1. private def getShuffleMapStage( 

2 shuffleDep :ShuffleDependency[_，，|] ， 

3: firstJobld : Int) :ShuffleMapStage = | 

4. shuffleToMapStage. get( shuffleDep. shuffleId ) match | 

Sh // 找 到 Stage 则 直接 返回 

6. case Some( stage) => stage 

也 // 和 否则 ,获取 所 有 没有 生成 Stage 的 ShuffleDependency, 并 以 此 生成 Stage 
8. case None => 

9. // 获 取 注 册 的 shuffle 父 依 赖 

10. getAncestorShuffleDependencies( shuffleDep. rdd). foreach { dep => 

TI shuffleToMapStage( dep. shuffleId) = newOrUsedShuffleStage( dep , firstJobId ) 
12 } 

13! // 注 册 当 前 的 shuffleDep 依赖 

14. val stage = newOrUsedShuffleStage( shuffleDep ,firstJobld ) 

|S shuffleToMapStage( shuffleDep. shuffleld) = stage 

16. stage 

7 | 

18. | 


DAGScheduler 的 getAncestorShuffleDependencies 方法 的 核心 逻辑 是 返回 在 shuffleToMap- 
Stage HashMap 中 不 存在 对 应 的 Stage 的 ShuffleDependency， 代 码 如 下 。 


1. private def getAncestorShuffleDependencies(rdd: RDD| _|) :Stack[ ShuffleDependency[ _,_,_|| 
=| 

2 val parents = new Stack[ ShuffleDependency| _,_,_||] 

3. val visited = newHashSet[ RDD[ _|] |] 

2 // 维 护 一 个 栈 , 防 止 由 于 递归 访 向 引起 的 栈 溢出 异常 (StackOverflowError) 

S. val waitingForVisit = new Stack[ RDD[ _|]] 

6. def visit(r:RDD[ _]) | 

gk if (lvisited(r)) | 

8. visited += r 

9. for(dep <— r. dependencies) | 

10. dep match | 

11. caseshufDep:ShuffleDependency[ _,_,_| => 

12. // 如 果 该 ShuffleDependency 没有 生成 过 Stage 

13: // 则 压 人 parents Stack 等 待 返回 

14. if ( lshuffleToMapStage. contains( shufDep. shuffleId) ) | 

is, parents. push( shufDep) 

16. } 

ys case _ => 

18. | 

19. waitingForVisit. push( dep. rdd ) 





2 


| 
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waitingForVisit. push(rdd ) 

while (waitingForVisit nonEmpty) | 
visit( waitingForVisit. pop( ) ) 

| 


parents 


DAGScheduler 的 newOrUsedShuffleStage 方法 的 代码 如 下 。 





1l. private def newOrUsedShuffleStage( 

权 shuffleDep :ShuffleDependency[_，， |] ， 

3. firstJobId:Int) :ShuffleMapStage = | 

4. valrdd = shuffleDep. rdd 

5 valnumTasks = rdd. partitions. length // 获 取 任 务 数目 

6. val stage = newShuffleMapStage(rdd ,numTasks ,shuffleDep ,firstJobId , rdd. creationSite) /新 
建 shuffleMapStage 

hs if ( mapOutputTracker. containsShuffle( shuffleDep. shuffleId) ) | 

8. valserLocs = mapOutputTracker. getSerializedMapOutputStatuses( shuffleDep. shuffleld ) 
9. vallocs = MapOutputTracker. deserializeMapStatuses( serLocs) 

10. (0 untillocs. length). foreach | i => 

11. if (locs(i) ne null) | 

2 //locs(i) will be null if missing 

13. stage. addOutputLoc(i,locs(i) ) 

14. } 

lS } 

16. | else | 

17. 因为 Partition 未 知 ,无 法 构造 RDD ,需要 在 mapOutputTracker 及 缓存 中 注册 RDD 
18. logInfo(" Registering RDD " +rdd.id+" (" +rdd. getCreationSite +")") 

19. mapOutputTracker. registerShuffle( shuffleDep. shuffleld ,rdd. partitions. length ) 

20. | 

2 stage 

2 


至 此 ， 整 个 DAGScheduler 划分 Stage 的 过 程 已 经 介绍 完毕 。Stage 划分 完成 后 ，DAG- 
Scheduler 就 会 回 到 HandleJobSubmitted 方法 中 调用 submitStage 方法 。 在 submitStage 方法 中 ， 
从 finalStage (ResultStage 对 象 实例 ) 开始 回 湖 ， 直 到 没有 Parent Stage 为 止 ， 提 交 整 个 Job 
的 所 有 Stage， 在 某 一 个 Stage，DAGScheduler 会 调用 submitMissingTasks 方法 把 Tasks 提交 给 
TaskScheduler 进行 细 粒 度 的 Task 调度 。 

下 面 介 绍 在 Stage 内 部 Task 获取 最 佳 位 置 的 算法 。 
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Stage 内 部 Task 获取 最 佳 位 置 的 算法 ) 


在 DAGScheudler 的 submitMissingTasks 方法 中 体现 了 利用 RDD 的 本 地 性 来 得 到 Task 的 
本 地 性 ， 从 而 获取 Stage 内 部 Task 的 最 佳 位 置 。DAGScheudler 的 submitMissingTasks 方法 会 
通过 调用 getPreferredLocs 方法 得 到 Task 最 佳 位 置 ， 并 把 结果 存放 到 taskIdToLocations Map 中 
以 便 使 用 。 

DAGScheudler 的 submitMissingTasks 方法 的 相关 部 分 关键 代码 如 下 : 








private def submitMissingTasks( stage: Stage, jobld :Int) | 


1 
之 
3 
4 // 首 先 标识 出 将 要 计算 分 区 的 索引 

3 val partitionsToCompute: Seq|[ Int | = stage. findMissingPartitions( ) 
6 

六 

8 

9 





val taskIdToLocations : Map| Int,Seq| TaskLocation | ] =try | 


10. stage match | 

11. case s:ShuffleMapStage => 

1 partitionsToCompute. map | id => (id,getPreferredLocs( stage. rdd,id) ) |. toMap 
js» case s:ResultStage => 

14. val job = s. activeJob. get 

15. partitionsToCompute. map | id => 

16. val p =s. partitions( id ) 

I (id, getPreferredLocs( stage. rdd,p) ) 

18. |. toMap 

19. } 

20. 

2 

22. stage. makeNewStageAttempt( partitionsToCompute. size ,taskIdToLocations. values. toSeq ) 
235 

24. 

2 val tasks:Seq[ Task[_]] =try | 

26. stage match | 

27: case stage:ShuffleMapStage => 

28. partitionsToCompute. map | id => 

29. val locs = taskIdToLocations (id) 

30. val part = stage. rdd. partitions( id) 

31. new ShuffleMapTask ( stage. id ,stage. latestInfo. attemptId ， 
3 由 taskBinary ,part , locs ,stage. internal Accumulators ) 
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34. 

35. case stage: ResultStage => 

36. val job = stage. activeJob. get 

SE partitionsToCompute. map | id => O) 
38. val p:Int = stage. partitions( id ) 

39. val part = stage. rdd. partitions( p) 

40. val locs = taskIdToLocations (id) 

41. new ResultTask( stage. id , stage. latestInfo. attemptId, 
42. taskBinary , part , locs ,id , stage. internalAccumulators ) 
43. | 

44. | 

45. | 

46. 

A 


DAGScheudler 的 getPreferredLocs 方法 只 是 调用 getPreferredLocsInternal 方法 。 
DAGScheudler 的 getPreferredLocs 方法 代码 如 下 。 


1. private[ spark ] 

2. def getPreferredLocs(rdd:RDD[_] ,partition:Int) :Seq[ TaskLocation | = | 
3 getPreferredLocsInternal( rdd ,partition ,new HashSet) 

a 


DAGScheudler 的 getPreferredLocsInternal 方法 具体 实现 了 一 个 Partition 的 数据 本 地 性 的 算 
法 。 在 具体 算法 实现 时 ， 首 先 查 询 DAGScheduler 的 内 存 数据 结构 中 是 否 存 在 当前 Paritition 
的 数据 本 地 性 的 信息 ， 如 果 有 则 直接 返回 ， 如 果 没 有 首先 会 调用 rdd. getPreferedLocations, 
例如 ， 想 让 Spark 运行 在 HBase 上 或 一 种 现在 还 没有 直接 支持 的 数据 库 上 面 ， 此 时 开发 者 需 
要 自 定 义 RDD， 为 了 保证 Task 计算 的 数据 本 地 性 ， 最 为 关键 的 方式 是 必须 实现 RDD 的 get- 
PreferedLocations ， 数 据 本 地 性 在 底层 运行 之 前 就 完成 了 。 

DAGScheudler 的 getPreferredLocsInternal 方法 代码 如 下 : 











1. private def getPreferredLocsInternal( 

2 rdd:RDD| _]， 

3 partition : Int, 

4 visited : HashSet| (RDDL_ | ,Int) ] ) :SeqlL TaskLocation | = | 
5. ”// 如 果 RDD 分 区 在 之 前 的 迭代 中 已 经 被 访问 过 ,就 没 必要 习 
6 

也 

8 

9 





访问 


喇 
六 








if ( lvisited. add( (rdd, partition) ) ) | 
// 如 果 分 区 之 前 已 经 询问 过 了 ,就 返回 Nil 


return Nil 





: | 
10. /首先 ,优先 获取 缓存 中 的 RDD 分 区 地 址 
11. val cached = getCacheLocs(rdd) (partition ) 
j 2 if (cached. nonEmpty) | 
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13. return cached 
人 
15. /然后 ,如 果 缓 存 中 没有 RDD 分 区 地 址 , 则 判断 RDD 本 身 是 否 有 首选 的 地 址 。 若 有 ,就 用 

















来 构造 TaskLocation 并 返回 
16. val rddPrefs = rdd. preferredLocations (rdd. partitions( partition ) ). toList 

lye if (rddPrefs. nonEmpty) | 

18. return rddPrefs. map( TaskLocation( _)) 

19. | 

20. ”// 最 后 ,如 果 RDD 有 窄 依赖 ,就 挑选 第 一 个 窄 依赖 的 第 一 个 分 区 的 首选 地 址 
21. rdd. dependencies. foreach | 








2 case n:NarrowDependency [_| => 

23. for (inPart <— n. getParents( partition) ) | 
2 val locs = getPreferredLocsInternal (mn. rdd ,inPart ,visited ) 
2 if (locs != Nil) | 

26. return locs 

27. | 

28. } 

29. 

30 case _ => 

31. } 

3 

$3) Nil 

34. | 


DAGScheduler 计算 数据 本 地 性 时 巧妙 地 借助 了 RDD 自身 的 getPreferedLocations 中 的 数 
据 ， 最 大 化 地 优化 效率 ， 因 为 getPreferedLocations 中 表明 了 每 个 Partition 的 数据 本 地 性 ， 虽 
然 当 前 Partition 可 能 被 persist 或 者 checkpoint ， 但 是 persist 或 者 checkpoint 默认 情况 下 肯定 是 
和 getPreferedLocations 中 的 Partition 数据 本 地 性 一 致 ， 所 以 这 就 极 大 地 简化 了 Task 数据 本 地 
性 算法 的 实现 和 效率 的 优化 。 








[HI 注意 ， 数 据 本 地 性 是 指 : 确定 数据 在 哪个 结 点 上 ， 就 到 哪个 结 点 的 Executor 上 去 运行 。 





底层 的 Task 调度 器 ( TaskScheduler ) 


TaskScheduler 的 核心 任务 是 提交 TaskSet 到 集群 运算 并 汇报 结 

1) 为 TaskSet 创建 和 维护 一 个 TaskSetManager， 并 追踪 任务 的 本 地 性 及 错误 信息 。 

2) 遇 到 Straggle 任务 会 放 到 其 他 结 点 进行 重 试 。 

3) 向 DAGScheduler 汇报 执行 情况 ， 包 括 在 Shuffle 输出 丢失 时 报告 fetch failed 错误 
等 信息 。 
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TaskScheduer 原理 剖析 ) 


通过 之 前 DAGScheduler 的 介绍 可 以 知道 ，DAGScheduler 将 划分 的 一 系列 Stage (每 个 
Stage 封装 一 个 TaskSet) ， 按 照 Stage 的 先后 顺序 依次 提交 给 底层 的 TaskScheduler 去 执行 。 下 
面 来 分 析 TaskScheduler 接收 到 DAGScheduler 的 Stage 任务 后 ， 是 如 何 管理 Stage (TaskSet ) 
的 生命 周期 的 。 

首先 ， 回 顾 一 下 DAGScheduler 在 SparkContext 中 实例 化 时 ，TaskScheduler 和 Scheduler- 
Backend 就 已 经 先 在 SparkContext 的 createTaskScheduler 创建 出 实例 对 象 了 。 











注意 ， 虽 然 Spark 支持 多 种 资源 部 署 模式 (包括 Local 、Standalone 、YARN 和 Mesos 等 ) ， 但 是 底层 调度 
器 TaskScheduler 接口 的 实现 类 都 是 TaskSchedulerImpl。 并 且 ， 为 了 方便 读者 理解 TaskScheduler， 对 于 
SchedulerBackend 的 实现 也 只 专注 Standalone 部 署 模式 下 的 具体 实现 SparkDeploySchedulerBackend 来 做 
分 析 。 





TaskSchedulerImpl 在 createTaskScheduler 方法 中 实例 化 后 ， 就 立即 调用 自己 的 initialize 
方法 把 SparkDeploySchedulerBackend 的 实例 对 象 传 进来 ， 从 而 赋值 给 TaskSchedulerImpl 的 
backend。 在 TaskSchedulerImpl 的 initialize 方法 中 ， 根 据 调度 模式 的 配置 创建 实现 了 Schedul- 
erBuilder 接口 的 相应 实例 对 象 ， 并 且 创 建 的 对 象 会 立即 调用 buildPools 创建 相应 数量 的 Pool 
存放 和 管理 TaskSetManager 的 实例 对 象 。 实 现 SchedulerBuilder 接口 的 具体 类 都 是 Scheduler- 
Builder 的 内 部 类 。 

1) FIFOSchedulableBuilder: 调度 模式 是 SchedulingMode. FIFO ， 使 用 先进 先 出 策略 调度 。 
这 是 默认 模式 ， 在 该 模式 下 ， 只 有 一 个 TaskSetManager 池 。 

2) FairSchedulableBuilder: 调度 模式 是 SchedulingMode. FAIR ， 使 用 公平 策略 调度 。 

在 createTaskScheduler 方法 返回 后 ，TaskSchedulerImpl 通过 DAGScheduler 的 实例 化 过 程 
设置 DAGScheduler 的 实例 对 象 ， 然 后 调用 自己 的 start 方法 。 在 TaskSchedulerImpl 调用 start 
方法 时 ， 会 调用 SparkDeploySchedulerBackend 的 start 方法 ， 在 SparkDeploySchedulerBackend 
的 start 方法 中 会 最 终 注册 应 用 程序 AppClient。TaskSchedulerImpl 的 start 方法 中 还 会 根据 配 
置 判 断 是 否 周 期 性 地 检查 任务 的 推测 执行 。 

TaskSchedulerImpl 启动 后 ， 就 可 以 接收 DAGScheduler 的 submitMissingTasks 方法 提交 过 
来 的 TaskSet 进行 进一步 处 理 。TaskSchedulerImpl 在 submitTasks 中 初始 化 一 个 TaskSetManag- 
er 对 其 生命 周期 进行 管理 ， 当 TaskSchedulerImpl 得 到 Worker 结 点 上 的 Executor 计算 资源 时 ， 
会 通过 TaskSetManager 来 发 送 具 体 的 Task 到 Executor 上 执行 计算 。 

如 果 Task 执行 过 程 中 有 错误 导致 失败 ， 会 调用 TaskSetManager 来 处 理 Task 失败 的 情况 ， 
进而 通知 DAGScheduler 结束 当前 的 Task。TaskSetManager 会 将 失败 的 Task 再 次 添加 到 待 执 
行 的 Task 队列 中 。 








注意 , Spark Task 允许 失败 的 次 数 默 认 是 4 次 ， 在 TaskSchedulerImpl 初始 化 时 通过 spark. task. maxFailures 
设置 该 默认 值 。 











© 
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如 果 Task 执行 完毕 ， 执 行 的 结果 会 反馈 给 TaskSetManager， 由 TaskSetManager 通知 
DAGScheduler。DAGScheduler 根据 是 否 还 存在 待 执行 的 Stage ， 继 续 迭 代 提 交 对 应 的 TaskSet 
给 TaskScheduler 去 执行 ,或 者 输出 Job 的 结 

结合 第 5 章 执行 需 (Executor) 可 知 ， 通 过 下 面 的 调度 链 ，Executor 把 Task 执行 的 结果 
返回 给 调度 器 (Scheduler) 。 


1) 
2) 
3) 
4) 
5) 
6) 
7) 
8) 
9) 








Executor. run 。 

CoarseGrainedExecutorBackend. statusUpdate ( 发 送 StatusUpdate 消息 ) 。 
CoarseGrainedSchedulerBackend. receive ( 处理 StatusUpdate 消息 ) 。 
TaskSchedulerImpl. statusUpdate。 

TaskResultGetter. enqueueSuccessfulTask 或 者 enqueueFailedTask 。 
TaskSchedulerImpl. handleSuccessfulTask 或 者 handleFailedTask 。 
TaskSetManager. handleSuccessfulTask 或 者 handleFailedTask 。 
DAGScheduler. taskEnded 。 

DAGScheduler. handleTaskCompletion 。 


上 面 的 调度 链 值得 关注 的 是 : 第 7) 步 中 ，TaskSetManager 的 handleFailedTask 方法 会 将 
失败 的 Task 再 次 添加 到 待 执行 Task 队列 中 。 在 第 6) 步 中 ，TaskSchedulerImpl 的 handle- 
FailedTask 方法 在 TaskSetManager 的 handleFailedTask 方法 返回 后 ， 会 调用 CoarseGrained- 
SchedulerBackend 的 reviveOffers 方法 给 重新 执行 的 Task 获取 资源 。 


TaskScheduer 源 代 码 解 析 


下 面 通过 源 代码 解析 来 看 一 下 TaskScheduler 是 如 何 调度 和 管理 TaskSet 的 任务 。 
1，TaskScheduler 实例 化 源 代码 

TaskScheduler 和 DAGScheduler 都 在 SparkContext 实例 化 的 时 候 一 同 实 例 化 。 
SparkContext 源 代码 中 与 TaskScheduler 实例 化 相关 的 代码 如 下 。 











1. 

2.  @ volatile private var _taskScheduler:TaskScheduler = _ 

3. 

4. ee 

Ss private| spark | def taskScheduler:TaskScheduler = _taskScheduler 
6. private| spark | def taskScheduler_= (ts:TaskScheduler) :Unit = | 
Th _taskScheduler = ts 

8. } 

0 

10. ”// 实 例 化 SchedulerBackend 对 象 和 TaskScheduler 对 象 

ll. val (sched,ts) = SparkContext. createTaskScheduler(this ,master) 
12. _schedulerBackend = sched 

13. _taskScheduler = ts 

14. 

15. /实例 化 DAGScheduler 对 象 
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16. _dagScheduler = new DAGScheduler( this) 


18. ”// 启 动 TaskScheduler 实例 对 象 , 等 待 DACScheduler 提交 TaskSet 给 TaskScheduler 


19.  _taskScheduler. start( ) OO 


203 


SparkContext 的 createTaskScheduler 方法 中 与 Standalone 部 署 模式 相关 的 代码 如 下 。 








1l. /i** 

2 * Create a task scheduler based on a given master URL. 

3 * Return a 2 ~ tuple of the scheduler backend and the task scheduler. 

4. */ 

5. private def createTaskScheduler( 

6. sc :SparkContext, 

了 master:String) :(SchedulerBackend ,TaskScheduler) = | 

8. 

9. 

10. master match | 

le 

12. //Spark Standalone 部 署 模式 下 TaskScheduler 和 SchedulerBackend 分 别 由 各 自 对 应 
13. // 的 实现 类 TaskSchedulerImpl 和 SparkDeploySchedulerBackend 来 实例 化 对 象 
14. case SPARK_RECEX(sparkUrl) => 

US val scheduler = new TaskSchedulerImpl( sc) 

16. val masterUrls = sparkUrl. split(","). map("spark://" +_) 

Wa val backend = new SparkDeploySchedulerBackend( scheduler, sc , masterUrls) 
18. scheduler. initialize( backend ) 

19. (backend , scheduler) 

20. 

2 

2 } 

2 

2 


2. TaskScheduler 初始 化 源 代码 

TaskScheduler (实际 上 在 实现 类 TaskSchedulerImpl 的 initialize 方法 中 ) 在 初始 化 的 过 程 
中 设置 对 SchedulerBackend 对 象 的 引用 ， 实 例 化 SchedulerBuilder 具体 实现 类 的 对 象 用 来 创建 
和 管理 TaskSetManager 池 。 

TaskSchedulerImpl 源 代码 中 的 相关 代码 如 下 。 


1. // 上 默认 的 调度 模式 是 先进 先 出 (FIFO) 

2. private val schedulingModeConf = conf get( "spark. scheduler. mode" ," FIFO" ) 
3. val schedulingMode:SchedulingMode =try | 

4 SchedulingMode. withName( scheduling ModeContf. toUpperCase ) 
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| catch | 


号 
| 

了 def initialize( backend :SchedulerBackend) | 
8 // 设 置 对 SchedulerBackend 对 象 的 引用 
9 this. backend = backend 

10. /A/rootpoot 的 名 字 和 暂时 设置 为 空 值 



























































11. rootPool = new Pool( "" ,schedulingMode,0,0) 

DR schedulableBuilder = | 

13. schedulingMode match | 

14. // 调 度 模 式 是 FIFO 

15. case SchedulingMode. FIFO => 

16. //FIFOSchedulableBuilder 的 rootPool 里 面 直接 添加 TaskSetManager 
17. new FIFOSchedulableBuilder( rootPool ) 

18. // 调 度 模式 是 FAIR 

19. case SchedulingMode. FAIR => 

20. //FairSchedulableBuilder 的 rootPool 根据 配置 文件 可 以 挂 若干 个 子 pool， 
21. // 每 个 pool 里 面 都 添加 TaskSetManager 

2 new FairSchedulableBuilder( rootPool , conf ) 

23. | 

24. | 


23 // 构 建 TaskSetManager 池 
26. schedulableBuilder. buildPools( ) 
2 


3. TaskScheduler 启动 源 代码 
TaskScheduler 实例 对 象 在 DAGScheduler 实例 化 之 后 启动 ， 并 且 TaskScheduler 启动 的 过 





程 由 TaskSchedulerImpl 具体 实现 。 在 启动 过 程 中 ， 主 要 是 调用 SchedulerBackend 的 启动 方 


法 ， 
况 ， 
的 扒 











然后 对 不 是 本 地 部 署 模式 并 且 开 启 任 务 的 推测 执行 (设置 spark. speculation 为 tue) 情 
根据 配置 判断 是 否 周 期 性 地 调用 TaskSetManager 的 checkSpeculatableTasks 方法 检查 任务 








测 执行 。SparkDeploySchedulerBackend 的 start 方法 中 会 最 终 注册 应 用 程序 AppClient。 关 


于 SchedulerBackend 的 更 多 源 代码 解析 请 参考 4.6 节 。 








TaskSchedulerImpl 源 代码 中 的 start 方法 的 相关 代码 如 下 。 


override def start( ) | 
//Spark Standalone 部 署 模 式 下 调用 SparkDeploySchedulerBackend 的 start 方法 ， 
//SparkDeploySchedulerBackend 的 start 方法 中 会 最 终 注 册 应 用 程序 AppClient 
backend. start( ) 
































// 不 是 本 地 部 署 模式 并 且 开 启 了 任务 的 推测 执行 
if ( lisLocal && conf getBoolean( " spark. speculation" ,false) ) | 





logInfo( " Starting speculative execution thread" ) 


speculationScheduler. scheduleAtFixedRate( new Runnable | 
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override def run( ) :Unit = Utils. tryOrStopSparkContext( sc) | 
// 最 终 会 调用 调度 池 中 的 TaskSetManager 的 checkSpeculatableTasks 方法 
// 来 检查 推测 执行 的 任务 
checkSpeculatableTasks( ) O) 





} ,SPECULATION _ INTERVAL MS, SPECULATION INTERVAL _ MS, 


TimeUnit. MILLISECONDS) 


4. TaskScheduler 提交 任务 源 代码 

TaskSchedulerImpl 启动 后 ， 就 可 以 接收 DAGScheduler 的 submitMissingTasks 方法 提交 过 
来 的 TaskSet 进行 进一步 处 理 了 。 对 于 ShuffleMapStage 类 型 的 Stage，DAGScheduler 初始 化 一 
组 ShuffleMapTask 实例 对 象 ， 对 于 ResultStage 类 型 的 Stage，DAGScheduler 初始 化 一 组 Re- 
sultTask 实例 对 象 。 最 后 ，DAGScheduler 将 这 组 ResultTask 实例 对 象 封装 成 TaskSet 实例 对 象 
提交 给 TaskSchedulerImpl。 

注意 ，ShuffleMapTask 是 根据 Stage 所 依赖 的 RDD 的 partition 分 布 产 生 跟 partition 数量 相 
等 的 Task， 这 些 Task 根据 partition 的 本 地 性 分 布 在 不 同 的 集群 结 点 ; ResultTask 负责 输出 整 


个 Job 的 结 











DAGScheduler 的 submitMissingTasks 方法 的 部 分 关键 代码 如 下 。 


ye CA de re 


a 
I 


/ ** Called when stage s parents are available and we can now do its task. */ 
private def submitMissingTasks( stage: Stage, jobld:Int) | 


logDebug( "submitMissingTasks(" +stage +" )") 


val tasks:Seq[ Task[ _]] =try | 
stage match | 


// 对 于 ShuffleMapStage ,初始 化 一 组 ShuffleMapTask 实例 对 象 


case stage:ShuffleMapStage => 
partitionsToCompute. map | id => 
vallocs =taskIdToLocations( id) 
val part = stage. rdd. partitions( id) 
new ShuffleMapTask ( stage. id , stage. latestInfo. attemptld, 

taskBinary , part ,locs , stage. internal Accumulators ) 
| 
// 对 于 ResultStage ,初始 化 一 组 ResultTask 实例 对 象 


case stage:ResultStage => 
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val job = stage. activeJob. get 


partitionsToCompute. map | id => 
val p:Int = stage. partitions( id ) 
val part = stage. rdd. partitions( p) 
val locs = taskIdToLocations( id) 
new ResultTask (stage. id ,stage. latestInfo. attemptld, 


taskBinary ,part , locs ,id , stage. internal Accumulators ) 


| catch | 


if (tasks. size > 0) | 
logInfo( "Submitting " +tasks. size +" missing tasks from " +stage +" (" +stage.rdd +")") 
stage. pendingPartitions ++= tasks. map(_. partitionId ) 


logDebug("New pending partitions:" + stage. pendingPartitions ) 

// 将 生成 的 所 有 Task 封装 成 一 个 TaskSet, 提交 给 TaskScheduler 的 submitTasks 
// 实 际 上 调用 TaskSchedulerImpl 的 submitTasks 方法 进一步 处 理 
taskScheduler. submitTasks( new TaskSet( 


tasks. toArray ,stage. id ,stage. latestInfo. attemptId , jobld , properties) ) 








stage. latestInfo. submissionTime = Some( clock. getTimeMillis( ) ) 


| else | 





TaskSchedulerImpl 在 submitTasks 中 初始 化 一 个 TaskSetManager ， 并 通过 SchedulerBuilder 
对 其 生命 周期 进行 管理 ， 最 后 调用 SchedulerBackend 的 reviveOffers 方法 进行 TaskSet 所 需 资 
源 的 分 配 。 在 TaskSet 得 到 足够 的 资源 后 ， 在 SchedulerBackend 的 launchTasks 方法 中 将 Task- 
Set 中 的 Task 一 个 一 个 地 发 送 到 Executor 去 执行 。 

TaskSchedulerImpl 的 submitTasks 方法 的 部 分 关键 代码 如 下 。 














override def submitTasks(taskSet:TaskSet) | 


val tasks = taskSet. tasks 
logInfo( " Adding task set " +taskSet. id +" with " +tasks. length +" tasks" ) 
this. synchronized | 
val manager = createTaskSetManager( taskSet, maxTaskFailures) 
val stage = taskSet. stageld 
val stageTaskSets = 
taskSetsByStageldAndAttempt. getOrElseUpdate( stage, new HashMap| Int,TaskSetManager | ) 
stageTaskSets( taskSet. stageAttemptld) = manager 
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10. val conflictingTaskSet = stageTaskSets. exists | case (_,ts) => 

li ts. taskSet | = taskSet && | its. isZombie 

| | 
GS O) 
14. //SchedulerBuilder 将 新 建 的 TaskSetManager 实例 对 象 添加 到 关联 的 Pool 中 
15. schedulableBuilder. addTaskSetManager( manager,manager. taskSet. properties ) 

16. 

17. // 对 于 非 本 地 部 署 模 式 , 如果 没有 接收 到 Task , 就 周期 性 地 警告 或 者 取消 Task 
18. if (| isLocal && | hasReceivedTask) | 

19. starvationTimer. scheduleAtFixedRate( new TimerTask( ) | 

20. override def run( ) | 

2 if (! hasLaunchedTask) | 

2 logWarning( " Initial job has not accepted any resources;" + 

2 "check your cluster UI to ensure that workers are registered " + 

24. "and have sufficient resources" ) 

2 | else | 

26. this. cancel( ) 

27. | 

28. | 

255 1 ,STARVATION_TIMEOUT_MS ,STARVATION_TIMEOUT_MS ) 

30. } 

Si hasReceivedTask = true 

32. } 


23 //Spark Standalone 部 署 模式 调用 SparkDeploySchedulerBackend 的 reviveOffers 方法 
34. /进行 TaskSet 所 需 资源 的 分 配 ,在 得 到 足够 的 资源 后 ,将 TaskSet 中 的 Task 

5, // 一 个 一 个 地 发 送 到 Executor 去 执行 

36. backend. reviveOffers ( ) 

1 全 


接 下 来 继续 讲解 SchedulerBackend 的 原理 谢 析 和 源 代码 解析 。 


调度 器 的 通信 终端 ( SchedulerBackend ) 


匡 6. SchedulerBackend 原理 | 


以 Spark Standalone 部 署 方式 为 例 ，SparkDeploySchedulerBackend 在 启动 时 构造 了 App- 
Client 实例 ， 并 在 该 实例 start 时 启动 了 ClientEndpoint 消息 循环 体 ，ClientEndpoint 在 在 启动 时 
会 向 Master 注册 当前 程序 。 而 SparkDeploySchedulerBackend 的 父 类 CoarseGrainedScheduler- 
Backend 在 start 时 会 实例 化 类 型 为 DriverEndPoint (这 就 是 程序 运行 时 的 经 典 对 象 Driver) 的 

















内 核 机 制 解析 及 性 能 调 优 





消息 循环 体 ，SparkDeploySchedulerBackend 专门 负责 收集 Worker 上 的 资源 信息 ， 当 Executor- 
Backend 启动 时 会 发 送 RegisteredExecutor 信息 向 DriverEndpoint 注册 ， 此 时 SparkDeploySched- 
ulerBackend 就 掌握 了 当前 应 用 程序 拥有 的 计算 资源 ，TaskScheduler 就 是 通过 SparkDeploy- 
SchedulerBackend 拥有 的 计算 资源 来 具体 运行 Task 的 。 








SchedulerBackend 源 代 码 解 析 ) 


下 面 通 过 源 代码 解析 来 看 一 下 Spark Standalone 部 署 方式 下 的 SparkDeploySchedulerBack- 
end 是 如 何 收 集 和 分 配 资 源 给 调度 的 Task 用 的 。 
SparkDeploySchedulerBackend 的 start 方法 的 相关 代码 如 下 。 

















1. override def start( ) | 

2 // 先 调用 父 类 CoarseGrainedSchedulerBackend 的 start 方法 

3. super. start( ) 

4. launcherBackend. connect( ) 

和 

6. //Executor 的 endpoint 循环 消息 体 进行 汇报 

7: val driverUrl = rpcEnv. uriOf( SparkEnv. driverActorSystemName, 

8. RpcAddress( sc. conf. get( " spark. driver. host" ) ,sc. conf. get( " spark. driver. port" ). toInt ) ， 
9 CoarseGrainedSchedulerBackend. ENDPOINT_NAME) 

10. val args =Seq( 

11. " —— driver — url" ,driverUrl ， 

I " —— Executor -id" ," | |EXECUTOR_ID}}", 

13. " ——hostname" ," | |HOSTNAME}}", 

14. " ——cores"," | |CORES}}", 

15. "app—id","| |APP ID}}", 

16. " ——worker -ul","||WORKER_URL}}") 

17. val extraJavaOpts = sc. conf. getOption( " spark. Executor. extraJavaOptions" ) 
18. . map( Utils. splitCommandString ). getOrElse( Seq. empty ) 

19. val classPathEntries = sc. conf getOption( " spark. Executor. extraClassPath" ) 
20. . map(_. split( java. io. File. pathSeparator). toSeq). getOrElse( Nil) 

21. val libraryPathEntries = sc. conf. getOption( "spark. Executor. extraLibraryPath" ) 
228 .map(_. split( java. io. File. pathSeparator). toSeq). getOrElse( Nil) 

2 

24. 





25. ”//Executor 注册 时 需 提供 的 必要 的 一 些 配 置信 息 
26. val sparkJavaOpts = Utils. sparkJavaOpts( conf, SparkConf. isExecutorStartupConf ) 

2 val javaOpts = sparkJavaOpts + + extraJavaOpts 

28. /指定 了 具体 为 当前 应 用 程序 启动 Executor 进程 的 入 口 类 

29.  // 为 CoarseGrainedExecutorBackend 

30. val command = Command ( " org. apache. spark. Executor. CoarseGrainedExecutorBackend", 


args ,sc. ExecutorEnvs ,classPathEntries + + testingClassPath ,libraryPathEntries,javaOpts) 
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sil val appUIAddress = sc. ui. map( _. appUIAddress). getOrElse("") 

32: val coresPerExecutor = conf. getOption( " spark. Executor. cores" ). map(_. toInt) 
33. /将 当前 Application 的 所 有 相关 信息 分 装 在 ApplicationDescription 实例 对 象 中 
34. val appDesc = new ApplicationDescription ( sc. appName, maxCores, sc. ExecutorMemory, com- O) 
mand , appUIAddress , sc. eventLogDir , sc. eventLogCodec , coresPerExecutor) 

35. /创建 AppClient 实例 对 象 ,用 于 Application 跟 Spark 部 署 的 集群 通信 

36. client = newAppClient( sc. env. rpcEnv ,masters ,appDesc ,this ,conf ) 

37. // 启动 AppClient ,其 方法 内 部 会 创建 其 内 部 类 ClientEndpoint 的 实例 对 象 

38. client start( ) 

39. launcherBackend. setState( SparkAppHandle. State. SUBMITTED ) 

40. waitForRegistration( ) 

41. launcherBackend. setState( Spark AppHandle. State. RUNNING) 

42. | 








SparkDeploySchedulerBackend 的 父 类 CoarseGrainedSchedulerBackend 的 start 方法 和 相关 
代码 如 下 。 


1. override def start( ) | 

2 val properties = newArrayBuffer| (String,String) ] 

3 for ( (key,value) <— scheduler sc. conf getAll) | 
4 if (key. startsWith( "spark." )) | 

5 properties += ((key,value) ) 
6 

有 

8 

9 





// 创 建 CoarseGrainedSchedulerBackend 内 部 类 DriverEndpoint 的 实例 对 象 作 为 消息 
10. // 循 环 体 ,以 便 处 理 接收 的 主要 消息 RegisterExecutor( 这 个 消息 来 自 ExecutorBackend) 
11. driverEndpoint = rpcEnv. setupEndpoint ( ENDPOINT_ NAME , createDriverEndpoint ( proper- 
ties ) ) 
1220000 





14. private[ spark | object CoarseGrainedSchedulerBackend | 
15. val ENDPOINT_NAME = " CoarseGrainedScheduler" 
16. | 


AppClient 的 start 方法 的 代码 如 下 。 


1. def start() | 

2 // Just launch an rpcEndpoint;it will call back into the listener. 

3 // 创 建 AppClient 内 部 类 ClientEndpoint 的 实例 对 象 作为 消息 循环 体 ， 
A // 以 便 向 Master 注册 当前 的 Application 
5 

6 





endpoint. set( rpcEnv. setupEndpoint( " AppClient " ,new ClientEndpoint (rpcEnv) ) ) 
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接 下 来 继续 讲解 Spark 程序 的 的 注册 机 制 。 





Spark 程序 的 注册 机 制 ) 


在 上 面 的 源 代码 分 析 中 ，AppClient 在 启动 时 创建 了 AppClient 内 部 类 ClientEndpoint 的 
实例 对 象 作 为 消息 循环 体 ， 以 便 向 Master 注册 当前 的 Application。 既 然 ClientEndpoint 是 Rp- 
cEndpoint 的 子 类 ， 那 么 就 会 有 这 样 的 生命 周期 ，constructor 一 onStart 一 receive 一 onStop。 根 据 
这 个 原理 ， 来 看 一 下 ClientEndpoint 的 onStart 方法 的 代码 。 





1. override def onStart( ) :Unit = | 

2 try | 

3 // 向 Master 注册 Application ,参数 1 代表 第 1 次 尝试 注册 
4 registerWithMaster( 1 ) 

5, | catch | 

6 case e:Exception => 

又 logWarning( " Failed to connect to master" ,e) 

8 markDisconnected( ) 

9 


stop( ) 


ClientEndpoint 在 启动 时 就 立即 调用 registerWithMaster 来 注册 Application ， 继 续 查 看 reg- 
isterWithMaster 方法 的 代码 。 























1. private def registerWithMaster( nthRetry:Int) | 

多 // 问 所 有 Master 异步 地 尝试 注册 Application 

3 registerMasterF utures. set( tryRegisterAll]Masters( ) ) 

4 registrationRetryTimer. set( registrationRetryThread. scheduleAtFixedRate( new Runnable | 
Ss override def run( ) :Unit = | 

6 Utils. tryOrExit | 

7 // 如 果 已 经 注册 过 ,那么 就 取消 问 其 他 Master 的 注册 ,并 且 关 闭 注册 用 的 线程 池 
8 if (registered. get) | 

9 registerMasterFutures. get foreach( _. cancel( true) ) 

10. registerMasterThreadPool. shutdownNow( ) 

11. // 如 果 注 册 尝 试 次 数 等 于 或 者 超过 3 次 ,就 表明 本 次 注册 失败 

I | else i{ (nthRetry >= REGISTRATION_RETRIES) | 

13. markDead( " All masters are unresponsive! Giving up.") 

14. // 否 则 继续 尝试 向 Master 注册 Application 

lls. | else | 

16. registerMasterF' utures. get. foreach( _. cancel( true) ) 

I registerWithMaster( nthRetry + 1) 
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19. | 

20. | 

2 // 每 次 注册 过 程 的 时 间 不 能 超过 20s ,否则 注册 失败 

2 | , REGISTRATION_TIMEOUT_SECONDS, REGISTRATION_TIMEOUT_SECONDS, Time- O) 
Unit SECONDS) ) 

鸡 ， | 


ClientEndpoint 在 tryRegiesterAllMasters 方法 中 会 向 所 有 的 Master 尝试 注册 Application 。 
相关 方法 的 代码 如 下 。 


1. private def tryRegisterAllMasters( ) :Array[ JFuture[ _|] ] = | 

2 for (masterAddress <— masterRpcAddresses) yield | 

3 registerMasterThreadPool. submit( new Runnable | 

4 override def run( ) :Unit = try | 

Sa if (registered. get) | 

6 return 

7 | 

8 logInfo( " Connecting to master " + masterAddress. toSparkURL +"...") 
9 valmasterRef = 

10. rpcEnv. setupEndpointRef( Master. SYSTEM_NAME ,masterAddress ,Master. 
ENDPOINT_ NAME ) 

站 // 给 Master 发 送 RegisterApplication 消息 处 理 Application 的 注册 
2 masterRef send( RegisterApplication( appDescription ,self) ) 

13. | catch | 

14. case ie:InterruptedException => // Cancelled 

5 case NonFatal (e) => logWarning (s" Failed to connect to master $ masterAd- 
dress" ,e) 

16. } 

Uy }) 

18. } 

19. } 





Master 也 是 RpcEndpoint 的 子 类 ， 所 以 可 以 通过 receive 方法 接收 DeployMessage 类 型 的 
消息 RegisterApplication。 部 分 相关 代码 如 下 。 


override def receive:PartialFunction[ Any, Unit | = | 


case RegisterApplication( description, driver) => | 
// 忽 略 STANDBY 状态 的 Master 
if (state == RecoveryState. STANDBY) | 


// ignore, don t send response 


09005 


| else | 
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由 logInfo( " Registering app " + description. name ) 

10. // 创 建 ApplicationInfo 实例 对 象 ,封装 诸如 系统 时 间 戳 .Application ID .默认 Applica- 
tion 需要 的 最 大 CPU Core 数量 和 ClientEndpoint 的 引用 等 信息 

11. val app = createApplication( description , driver) 

六 // 具 体 注册 Application 到 Master 对 象 的 内 存 结构 中 

13. registerApplication( app) 

14. logInfo( " Registered app " + description. name +" with ID " +app. id) 

es // 将 新 创建 的 Application 持久 化 ,以 便 错 误 能 恢复 

16. persistenceEngine. addApplication( app) 

ly // 返 回 AppClient. ClientEndpoint 的 receive 方法 处 理 RegisteredApplication 消息 
18. driver. send( RegisteredApplication( app. id ,self) ) 

19. // 给 注册 好 的 Application 分 配 Executor 资源 

20. schedule( ) 

2 | 

玉 | 

2 

24. private def registerApplication( app: ApplicationInfo) :Unit = | 

2 val appAddress = app. driver. address 

26. // 忽 略 相 同 地 址 的 Application 的 注册 

Tk if (addressToApp. contains( appAddress) ) | 

28. logInfo( " Attempted to re — register application at same address:" + appAddress) 
2 return 

30. } 

3 

3 applicationMetricsSystem. registerSource( app. appSource) 

33; // 将 注册 好 的 Application 加 入 到 Master 维护 的 关于 Application 的 成 员 变 量 中 
34. apps += app 

358 idToApp( app. id) = app 

36. endpointToApp( app. driver) = app 

3 addressToApp( appAddress) = app 

38. waitingApps += app 

29 

40. | 


ClientEndpoint 最 后 在 receive 方法 中 得 到 来 自 Master 注册 好 Application 的 确认 。 部 分 相 
关 代 码 如 下 。 


a 








override def receive :PartialFunction| Any, Unit | = | 


case RegisteredApplication( appld_, masterRef) => 


// 保 存 Master 返回 的 Application ID 
appld. set(appId_) 
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6 // 标 记 Application 注册 完毕 

7 registered. set( true) 

8. // 保 存 Master 的 通信 端的 引用 

9 master = Some( masterRef) O) 


10. listener. connected ( appld. get) 























12. | 


至 此 ，Application 向 Master 注册 完毕 。 在 上 面 的 RegisterApplication 中 调用 了 schedule 方 
法 ， 这 个 方法 将 完成 Application 的 调度 ， 并 在 Worker 结 点 上 启动 分 配 好 的 Executor 给 Appli- 
cation 使 用 。 关 于 具体 如 何 把 Executor 分 配给 Application ， 请 参考 第 5 章 执 行 器 ( Executor) 
的 解析 。 








Spark 程序 对 计算 资源 Executor 的 管理 ) 


从 TaskSchedulerImpl 的 submitTasks 的 方法 中 可 以 知道 ，Spark Standalone 部 署 模式 调用 
SparkDeploySchedulerBackend 的 reviveOffers 方法 进行 TaskSet 所 需 资源 的 分 配 ， 在 得 到 足够 
的 资源 后 ， 将 TaskSet 中 的 Task 一 个 一 个 地 发 送 到 Executor 去 执行 。 下 面 来 看 一 下 这 里 的 资 
源 即 Executor 是 如 何 得 到 和 分 配 的 。 

SparkDeploySchedulerBackend 的 reviveOffers 方法 很 简单 ， 就 是 发 送 一 个 ReviveOffers 消 
息 给 内 部 类 DriverEndpoint， 代 码 如 下 。 





1. override def reviveOffers( ) | 
虽 // DriverEndpoint 是 RpcEndpoint 的 子 类 ,会 在 receive 方法 里 处 理 ReviveOffers 消息 
3. driverEndpoint. send( ReviveOffers) 

续 | 








DriverEndpoint 的 receive 方法 处 理 ReviveOffers 消息 也 很 简单 ， 就 是 调用 makeOffers 方 
法 ，receive 方法 的 部 分 关键 代码 如 下 。 


override def receive:PartialFunction[ Any, Unit | = | 


caseReviveOffers => 


1 
昂 
3 
4. // 回 调 DriverEndpoint 的 makeOffers 方法 
5) 
6 
又 





makeOffers( ) 


| 


DriverEndpoint 的 makeOffers 方法 首先 过 滤 出 Alive 状态 的 Executor 放 到 activeExecutors 
HahMap 变量 中 ， 然 后 使 用 id 、ExecutorData. ExecutorHost 和 ExecutorData. freeCores 构 建 代 表 
Executor 可 用 资源 的 WorkerOffer。 最 后 是 两 个 最 重要 的 方法 调用 。 先 是 调用 TaskScheduler- 
Impl 的 resourceOffers 得 到 TaskDescription 的 二 维 数 组 ， 包 含 Task ID 、Executor ID 和 Task In- 
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dex 等 Task 执行 需要 的 信息 。 然 后 回调 DriverEndpoint 的 launchTask 给 每 个 Task 对 应 的 Ex- 
ector 发 送 执行 Task 的 LaunchTask 消息 (其 实 是 由 CourseGrainedExecutorBackend 转发 
LauchTask 消息 ) 。DriverEndpoint 的 makeOffers 方法 的 代码 如 下 。 


11. 





a def makeOffers( ) | 


只 保留 Alive 状态 的 Executor 
val activeExecutors = ExecutorDataMap. filterKeys( ExecutorIsAlive ) 
// 构 建 代 表 Executor 可 用 资源 的 WorkOffer 


val workOffers = activeExecutors. map | case (id ,ExecutorData) => 





newWorkerOffer( id ,ExecutorData. ExecutorHost, ExecutorData. freeCores ) 
}. toSeq 
// 先 调用 TaskSchedulerImpl 的 resourceOffers 得 到 TaskDescripion 的 二 维 数 组 
// 然 后 回调 lauchTask 给 每 个 Task 对 应 的 Executor 发 送 LaunchTask 消息 
launchTasks ( scheduler. resourceOffers( workOffers ) ) 
| 


TaskSchedulerImpl 的 resourceOffers 方法 的 代码 如 下 。 





def resourceOffers( offers :Seq| WorkerOffer | ) :Seql Seq[ TaskDescription | | = synchronized | 


// Mark each slave as alive and remember its hostname 

// Also track if new Executor is added 

var newExecAvail = false 

for (o <— offers) | 
ExecutorIdToHost( o. ExecutorId ) = o. host 
ExecutorldToTaskCount. getOrElseUpdate( o. Executorld ,0 ) 
// 如 果 在 ExecutorByHost 中 没 找到 o. host, 则 加 入 新 的 Executor 
if ( !ExecutorsByHost. contains(o. host) ) | 








ExecutorsByHost( o. host) = new HashSet| String | () 
ExecutorAdded( o. Executorld ,o. host) 
newExecAvail = true 
| 
for (rack <— getRackForHost(o. host) ) | 
hostsByRack. getOrElseUpdate(rack ,new HashSet[ String]()) += o. host 


//[ 为 了 避免 将 Task 总 是 放 在 某 些 Worker 上 ,这 里 随机 打 散 这 些 Task 

val shuffledOffers = Random. shuffle( offers ) 

/构建 分 配 好 资源 的 Task 

val tasks =shuffledOffers. map(o => new ArrayBuffer[ TaskDescription | ( o. cores ) ) 





val availableCpus = shuffledOffers. map(o => o. cores). toArray 
// 得 到 调度 模式 排 好 序 的 TaskSetManager 


val sortedTaskSets = rootPool. getSortedTaskSetQueue 
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26. for (taskSet <— sortedTaskSets) | 


2 logDebug( " parentName:%s,name:%s,runningTasks:%s". format( 

28. taskSet. parent. name ,taskSet. name , taskSet. runningTasks ) ) 

29. if (newExecAvail) | O) 
30. taskSet. ExecutorAdded( ) 

3 } 

92 } 

33. 


34. // 按 照 调度 模式 排 好 的 顺序 获取 TaskSet, 然 后 按照 优先 分 配 的 就 近 原 则 分 配 资源 
35. // 优 先 分 配 的 就 近 原 则 依次 是 :PROCESS_LOCAL NODE_LOCAL NO_PRFEF RACK_LO- 


CAL 和 ANY 

36. var launchedTask = false 

S37 for (taskSet <— sortedTaskSets;maxLocality <— taskSet. myLocalityLevels) | 
38. do | 

9 // 为 每 个 TaskSet 分 配 Executor 和 CPU cores 资源 

40. launchedTask = resourceOfferSingleTaskSet( 

41. taskSet ,maxLocality ,shuffledOffers ,availableCpus ,tasks ) 
42. | while (launchedTask) 

2 

44. 

45. if (tasks. size > 0) | 

46. hasLaunchedTask = true 

47. | 

48. return tasks 

49， | 


TaskSchedulerImpl 的 resourceOffers 方法 返回 二 维 数组 TaskDescription 后 作为 Driver- 
Endpoint 的 launchTasks 方法 的 参数 。DriverEndpoint 的 launchTasks 方法 中 首先 对 传 入 的 
tasks 进行 扁平 化 操作 ( 例如， 将 多 维 数 组 降 维 成 一 维 数组 ) ， 得 到 所 有 的 Task， 然 后 遍历 
所 有 的 Task。 在 遍历 过 程 中 ,调用 serialize( ) 方 法 对 Task 进行 序列 化 ， 得 到 serialized- 
Task。 判 断 如 果 serialiedTask 大 于 等 于 Akka 帧 减 去 Akka 预 留 空间 大 小 ， 则 调用 TaskSet- 
Manager 的 abort 方法 终止 该 任务 的 执行 ， 和 否则， 将 LaunchTask (new SerializableBuffer (se- 
rializedTask) ) 消息 发 送 到 CoarseGrainedExecutorBackend 。 

DrvierEndpoint 的 akkaFrameSize 定义 和 launchTasks 方法 的 部 分 关键 代码 如 下 。 








private val akkaFrameSize = AkkaUtils. maxFrameSizeBytes( conf) 
private def launchTasks( tasks:Seq|[ Seql TaskDescription | ] ) | 


1 

色 

3 

2 for (task <— tasks. flatten) | 

3 val serializedTask = ser. serialize( task ) 
6 


// 判 断 如 果 serialiedTask 大 于 等 于 Akka 帧 减 去 Akka 预 留 空 间 大 小 , 则 调用 TaskSet- 
Manager 的 abort 方法 终止 该 任务 的 执行 
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肥 让 (serializedTask. limit >= akkaFrameSize - AkkaUtils. reservedSizeBytes ) | 
scheduler taskIdToTaskSetManager. get( task. taskId). foreach | taskSetMgr => 


号 : try | 


11. taskSetMgr. abort( msg) 
I2: | catch | 


14. } 

15. else | 

16. valExecutorData = ExecutorDataMap( task. ExecutorId ) 

I ExecutorData. freeCores -= scheduler. CPUS_ PER TASK 

18. // 将 LaunchTask ( new SerializableBuffer( serializedTask ) ) 消息 发 送 到 CoarseGraine- 
dExecutorBackend 

19. ExecutorData. ExecutorEndpoint send ( LaunchTask ( new SerializableBuffer ( serialized- 
Task) ) ) 

20. } 





Akka 通过 SparkConfig 中 配置 的 spark. akka. frameSize 取出 Akka 帧 大 小 的 配置 ， 默 认为 
128 MB ，Akka 预 留 空间 大 小 为 200 KB。 
Akka 的 maxFrameSizeBytes 方法 和 预 留 空间 代码 如 下 。 











1. def maxFrameSizeBytes( conf:SparkConf) :Int = | 

2 /AAkka 默认 帧 大 小 为 128MB 

3 val frameSizeInMB = conf. getInt( " spark. akka. frameSize" ,128 ) 
4. if (frameSizeInMB > AKKA MAX FRAME SIZE IN_MB) | 
S throw new IllegalArgumentException( 

6 s" spark. akka. frameSize should not be greater than $ AKKA MAX FRAME_SIZE_IN 
MB MB" ) 

% } 

8. frameSizeInMB * 1024 * 1024 

9. 

10. 


11. ”// 预 留 空间 大 小 为 200 KB 
12. val reservedSizeBytes =200 * 1024 





此 后 ，CoarseGrainedExecutorBackend 匹配 到 LaunchTask (data) 消息 后 ， 首 先 调用 dese- 
行 


rialized 方法 ， 反 序列 化 出 task， 然 后 调用 Executor 的 lauchTask( ) 方 法 执 


Task 的 处 理 。 具 





体 详 情 请 参阅 第 5 章 执行 器 ( Executor) 。 
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本 章 内 容 围 绕 Spark 调度 器 (Scheduler) 的 运行 机 制 ， 介绍 了 其 中 涉及 的 重要 概念 ， 如 
Spark Driver Program 、Spark Job、 高 层 调度 器 (DAGScheduler) 、 底 层 调 度 器 (TaskSchedul- 
er) 和 调度 器 的 通信 终端 (SchedulerBackend) 。 同 时 ， 从 外 围 的 运行 框架 到 内 部 的 调度 天 
和 通信 和 终端， 分别 深度 剖析 了 其 各 自 的 运行 原理 。 并 且 ， 结 合 Spark 源 代码 进行 解析 ， 从 而 
加 深 对 整个 Spark 调度 器 运行 机 制 的 理解 。 








注意 ， SparkContext、DAGScheduler 、TaskScheduler 和 SchedulerBackend 在 应 用 程序 启动 时 只 实例 化 一 次 ， 
应 用 程序 存在 期 间 始 终 存 在 这 些 对 象 。 
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Executor 是 Spark 中 执行 任务 的 进程 ， 它 能 被 不 同 的 调度 模式 所 调度 ， 例 如 Standalone、 
Mesos 、Yam。 本 章 主 要 讲解 Standalone 调度 模式 下 的 Executor， 在 Standalone 调度 模式 下 的 
Executor 中 ， 有 一 个 RPC (Remote Procedure Call) 远程 过 程 调用 接口 的 引用 ，Spark 1. 6.x 
版 本 中 ， 该 RPC 接口 有 两 种 不 同 的 实现 ， 分 别 是 Akka 和 Nety ， 目 前 默认 使 用 Netty 框架 实 
现 这 个 PRC 接口 ， 当 然 也 可 以 通过 spark. rpe 配置 项 指定 RPC 接口 的 实现 框架 ，Executor 正 
是 通过 该 RPC 接口 和 Driver 通信 的 。 为 了 让 大 家 从 整体 上 了 解 Spark 中 Executor 的 启动 过 
程 ， 给 出 如 图 5-1 所 示 的 时 序 图 。 


[时 序 图 | 图 
医 四 B CoarseGain 
ss ee | linent | 四 区 本 on ee | ySchedular AppClient ee edExecutor | | Executor 
hs bebe | | 
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图 5-1 Executor 启动 时 序 图 


使 用 spark - submit 提 交 程 序 到 集群 ，Master 会 接收 到 RequestSubmitDriver 请 求 ， 之 后 将 
会 调用 schedule 方法 把 Driver 程序 发 送 到 Worker 结 点 上 运行 。 当 Driver 程序 在 一 个 线程 中 
运行 起 来 后 ，SparkContext 得 到 初始 化 ， 之 后 会 创建 TaskScheduler 和 TaskSchedulerBackend 
(Standalone 模式 下 ) 。 在 启动 TaskSchedulerBackend 时 创建 AppClient，AppClient 是 一 个 Ac- 
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or， 在 其 peStart 方法 中 向 Master 注册 。Master 收 到 RegisterApplication 注册 请 求 后 ， 完 成 
Application 的 注册 ， 同 时 调用 schedule 方法 ， 向 Worker 结 点 发 送 LaunchExecutor 请 求 ， 满 足 
请 求 的 Worker 结 点 启动 线程 运行 ExecutorRunner， 在 ExecutorRunner 中 启动 CoarseGrainedEx- 
ecutorBackend， 在 CoarseGrainedExecutorBackend 中 创建 Executor， 并 完成 向 Driver 的 注册 。 

Executor 中 存在 一 个 线程 池 ， 该 线程 池 是 缓存 线程 池 (CachedThreadPool) ， 其 特点 是 如 
果 线 程 池 长 度 超过 处 理 需 要 ， 池 中 有 空闲 线程 ， 可 灵活 回收 空闲 线程 ; 若 不 能 满足 任务 处 
理 ， 则 新 建 线程 。 任 务 被 分 发 到 Executor 并 以 TaskRunner 的 形式 运行 于 线程 池 中 的 线程 
之 上 ; 





| Section | 


Executor 的 创建 、 人 分配、 启动 及 异常 处 理 








河 忆 出 Executor 的 创建 > 


上 面 通过 时 序 图 描述 了 Executor 的 调度 流程 ， 下 面 将 深入 源 代码 进一步 分 析 。 在 Spark- 
Context 启动 之 后 ，SparkDeploySchedulerBackend 中 会 new 出 一 个 AppClient，AppClient 中 有 
一 个 内 部 类 ClientEndPoint，ClientEndPoint 继承 自 ThreadSafeRpcEndpoint， 其 通过 RPC 机 制 
完成 和 Master 的 通信 。 在 ClientEndPoint 的 start 方法 中 ， 会 通过 registerWithMaster 方法 向 
Master 发 送 RegisterApplication 请 求 ，Master 收 到 该 请 求 消 息 之 后 ， 首 先 通过 registerApplica- 
tion 方法 完成 信息 登记 ， 之 后 将 会 调用 schedule 方法 ， 在 Worker 上 启动 Executor，Master 对 
RegisterApplication 请 求 处 理 的 源 代码 如 下 所 示 。 




















1. case RegisterApplication( description, driver) => | 

2 // TODO Prevent repeated registrations from some driver 

3 //Master 处 于 STANDBY( 备用 ) 状态, 不 做 处 理 

4 if (state == RecoveryState. STANDBY) | 

Sa // ignore,don t send response 

6 | else | 

7 logInfo( " Registering app " + description. name ) 

8 // 由 description 描述 ,构建 ApplicationInfo 

9 val app =createApplication( description, driver) 

10. registerApplication( app ) 

11. logInfo(" Registered app " + description. name +" with ID " +app. id) 
12: // 在 持久 化 引擎 中 加 入 application 

lS persistenceEngine. addApplication( app) 

14. // 问 worker 返回 注册 成 功 的 application Id 号 和 master 的 ul 
lS driver. send( RegisteredApplication( app. id ,self) ) 

16. // 调 用 schedule 方法 ,在 worker 结 点 上 启动 Executor 

17. schedule( ) } 





© 
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在 上 面 的 代码 中 ，Master 匹配 到 RegisterApplication 请 求 ， 先 判 岂 Master 的 状态 是 否 为 
STANDBY (备用 ) 状态 ， 如 果 不 是 说 明 Master 为 ALIVE 状态 ， 在 这 种 状态 下 ， 调 用 create- 
Application ( description, sender ) 方法 创建 ApplicationInfo， 完 成 之 后 调用 persisten- 
ceEngine. addApplication (app) 方法 ,将 新 创建 的 ApplicationInfo 持久 化 ， 以 便 错 误 恢复 。 
完成 这 两 步 操作 之 后 ， 通 过 sender ! RegisteredApplication (app. id ，masterUrl) 疝 AppClient 
返回 注册 成 功 后 ApplicationInfo 的 Id 和 master 的 url 地 址 。 

ApplicationInfo 对 象 是 对 application 的 描述 ， 先 来 看 一 下 createApplication 这 个 方法 的 源 
代码 ， 如 下 所 示 。 














private def createApplication( desc: ApplicationDescription , driver: RpcEndpointRef ) : 
ApplicationInfo = | 
//ApplicationInfo 创建 时 间 
val now = System. currentTimeMillis( ) 
val date = new Date( now) 
// 由 date 生成 application id 
val appld = new ApplicationId( date) 
// 创 建 ApplicationInfo 
new ApplicationInfo( now ,appld , desc , date , driver, defaultCores ) 


| 








Sd 


3 


上 面 代码 中 ，createApplication 方法 接收 ApplicationDescription 和 ActorRef 两 种 类 型 的 参 
数 。 使 用 newAppicationId 方法 生成 appId， 关 键 代码 如 下 。 





1. val appld ="app ~ %s— %04d". format( createDateFormat. format( submitDate) ,nextAppNumber ) 


因此 appId 的 格式 形 如 : app -20160429101010 -0001。 在 desc 这 个 对 象 中 ， 包 含 一 些 
基本 的 配置 ， 包括 从 系统 中 传人 的 一 些 配置 信息 ， 如 appname 、maxCores 和 memoryPerExec- 
utorMB 等 。 最 后 使 用 desc 、date 、driver 和 defaultCores 等 作为 参数 构造 一 个 ApplicatinInfo 对 
象 并 返回 。 也 数 返 回 之 后 ， 调 用 registerApplication 方法 ， 完 成 Application 的 注册 ， 该 方法 的 
代码 如 下 。 





. private def registerApplication( app: ApplicationInfo) :Unit = | 
//Driver 的 地 址 ,用 于 Master 和 Driver 通信 




















1 

2 

3 val appAddress = app. driver. address 

4. ”// 如 果 addressToApp 中 已 经 有 了 该 Driver 地 址 
5. /说 明 该 Driver 已 经 注册 过 了 , 直接 return 
6 

由 

8 

9 











if (addressToApp. contains( appAddress) ) | 
logInfo( " Attempted to re — register application at same address:" + appAddress) 
return 
l | 
10. ”// 癌 度量 系统 注册 


i application MetricsSystem. registerSource( app. appSource ) 
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12. ”//apps 是 一 个 HashSet, 保 存 数据 不 能 重复 向 HashSet 中 加 入 app 





13. apps += app 

14. /idToApp 是 一 个 HashMap, 问 该 HashMap 中 加 入 app 的 id 和 app 的 对 应 关系 

1S idToApp(app. id) = app O) 
16. ”//endpointToApp 是 一 个 HashMap ,记录 app 的 driver 和 app 的 对 应 关系 

I endpointToApp(app. driver) = app 


18. ”//addressToApp 是 一 个 HashMap ,记录 app Driver 的 地 址 和 app 的 对 应 关系 
19. addressToApp(appAddress) = app 

20. //waitingApps 是 一 个 数组 ,记录 等 待 调度 的 app 记录 

2 waitingApps += app 

2 


从 上 面 的 代码 中 可 以 看 到 ， 首 先 通过 app. driver. path. address 得 到 driver 的 地 址 ， 然 后 查 
看 appAdress 映射 表 中 是 否 已 经 存在 这 个 路 径 。 如 果 存 在 表示 该 Application 已 经 注册 ， 直 接 返 
回 ; 如 果 不 存 在 ， 则 在 waitingApps 数组 中 加 入 该 Application， 同 时 在 idToApp 、endpointToApp 
和 addressToApp 映射 表 中 加 入 映射 关系 。 加 入 waitingApps 数组 中 的 Application 等 待 schedule 
方法 的 调度 。 

schedule 方法 有 两 个 作用 ， 第 一 ， 完 成 Driver 的 调度 ， 将 waitingDrivers 数组 中 的 Driver 
发 送 到 满足 运行 条 件 的 Worker 上 运行 ; 第 二 ， 在 满足 条 件 的 Worker 结 点 上 为 Application 启 
动 Executor。schedule 方法 的 源 代码 如 下 所 示 。 
































1. private def schedule( ) :Unit=| 

2. 人 / 若 Master 的 状态 不 为 ALIVE 状态 ,直接 返回 

3 if (state ! = RecoveryState. ALIVE) | return | 

4. // Drivers take strict precedence over executors 

5. ”// 随 机 打 乱 Workers 这 个 HashSet 中 Worker 的 次 序 ,用 于 Driver 在 集群 中 随机 加 载 ,起 到 平 
衡 加 载 的 作用 ,从 这 里 也 可 以 看 出 ,Driver 是 在 集群 中 随机 的 Worker 上 启动 的 

















6. val shuffledWorkers = Random. shuffle( workers) // Randomization helps balance drivers 
7. /遍历 状态 为 ALIVE 的 Worker 

8. for (worker <— shuffledWorkers if worker state == WorkerState. ALIVE ) | 

9. [从 waitingDrivers 中 取出 Driver ,进行 匹配 

10. for (driver <— waitingDrivers) | 

11. /如 果 Driver 和 Worker 匹配 ,内存 和 运行 核 都 将 得 到 满足 

2 if (worker. memoryFree >= driver. desc. mem && worker. coresFree >= driver. 


desc. cores) | 


13. /在 该 Worker 上 启动 加 载 Driver 


14. launchDriver( worker, driver) 

15. /加 载 Driver 后 ,从 waitingDrivers 中 移 除 该 Driver 
16. waitingDrivers —= driver 

17. } 

18. } 

19. } 
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20. startExecutorsOnWorkers( ) /为 application 在 worker 上 启动 Executors 
2 








在 Master 中 ，schedule 方法 是 一 个 很 重要 的 方法 ， 每 一 次 新 的 Driver 的 注册 、Applica- 
tion 的 注册 或 者 可 用 资源 发 生变 动 ， 都 将 调用 schedule 方法 。schedule 方法 用 于 为 当前 等 待 
调度 的 Application 调度 可 用 的 资源 ， 在 满足 条 件 的 Worker 结 点 上 启动 Executor。 这 个 方法 还 
有 另外 一 个 作用 ， 就 是 当 有 Driver 提交 时 ， 负 责 将 Driver 发 送 到 一 个 可 用 资源 满足 Driver 需 
求 的 Worker 结 点 上 运行 ，launchDriver (worker，driver) 方法 负责 完成 这 一 任务 。 

Application 调度 成 功 之 后 ， Master 将 会 为 Appication 在 Worker 结 点 上 启动 Executors 调 
用 startExecutorsOnWorkers 方法 完成 此 操作 ， 其 源 代码 如 下 所 示 。 





1. private def startExecutorsOn Workers( ) :Unit = | 

久 // Right now this is a very simple FIFO scheduler. We keep trying to fit in the first app 

3 // in the queue ,then the second app ,etc. 

4 /遍历 没有 分 配 满 核 的 Application 

5. for (app <- waitingApps if app. coresLeft > 0) | 

6 //Application 中 指定 的 每 个 Executor 上 占用 核 的 个 数 

2 val coresPerExecutor:Option| Int | = app. desc. coresPerExecutor 

8 // 从 Workers 这 个 HashSet 中 过 滤 出 资源 可 用 的 Worker, 最 后 调用 reverse 方法 反 转 该 
Set 集合 ,使 coresFree 大 的 Worker 位 于 集合 的 前 面 ,优先 分 配 


























9. val usableWorkers = workers. toArray. filter( _. state == WorkerState. ALIVE) 

10. . filter( worker => worker. memoryFree >= app. desc. memoryPerExecutorMB && 
11. worker. coresFree >= coresPerExecutor getOrElse(1) ) 

1 . sortBy( _. coresFree). reverse 

I // 在 usableWorkers 中 分 配 处 理 需 

14. val assignedCores = scheduleExecutorsOnWorkers( app,usableWorkers ,spreadOutApps ) 
15. // Now that we ve decided how many cores to allocate on each worker ,let s allocate them 
16. for (pos <- 0 untilusableWorkers. length if assignedCores( pos) > 0) | 

ge // 为 Worker 上 的 Executors 实际 分 配 资源 

18. allocate WorkerResourceToExecutors( 

19. app , assignedCores( pos) ,coresPerExecutor, usableWorkers( pos) ) 

20. | 

2 } 

2200 


在 scheduleExecutorsOnWorkers 方法 中 ， 有 两 种 选择 启动 Executor 的 策略 ， 第 一 种 是 轮流 
均 摊 策略 (round - robin) ,采用 圆桌 算法 依次 轮流 均 扒 ,直到 满足 资源 需求 ， 轮 流 均 挫 策略 
通常 会 有 更 好 的 数据 本 地 性 ， 因 此 它 是 默认 的 选择 策略 。 第 二 种 是 依次 全 占 ， 在 usable- 
Workers 中 ， 依 次 获取 每 个 Worker 上 的 全 部 资源 ， 直 到 满足 资源 需求 。 

当 使 用 scheduleExecutorsOnWorkers 为 Application 分 配 好 资源 后 ，allocateWorkerResource- 
ToExecutors (app, assignedCores (pos ) ，coresPerExecutor ，usableWorkers (pos)) 方法 被 调 
用 ， 将 会 在 Worker 结 点 上 实际 分 配 资源 。 下 面 是 alocateWorkerResourceToExecutors 的 源 
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代码 。 











1. private def allocateWorkerResourceToExecutors( 

多 app:ApplicationInfo ， 

3 assignedCores :Int ， 

4. coresPerExecutor: Option| Int | ， 

S worker: WorkerInfo) :Unit = | 

6 // 如 果 Executor 指定 了 核 的 个 数 , 使 用 分 配 的 核 的 个 数 除 以 指定 核 的 个 数 , 确 定 出 要 
动 的 Executor 的 个 数 

有 val numExecutors = coresPerExecutor. map | assignedCores / _ |. getOrElse(1) 
8. // 如 果 coresPerExecutor 为 0, 则 取 assignedCores 并 赋值 给 coresToAssign 

9 val coresToAssign = coresPerExecutor getOrElse( assignedCores ) 

10. // 遍 历 numExecutors 中 所 有 的 Executor 

Mis for (i <— 1 to numExecutors) | 

12. // 在 app 中 加 入 Executor 信息 ,这 些 信息 包括 在 哪个 Worker 上 分 配 多 少 个 核 
13. val exec = app. addExecutor( worker, coresToAssign ) 

14. // 在 Worker 上 启动 Executor 

下 5 launchExecutor( worker ,exec ) 

16. // 启 动 之 后 将 app 状态 置 为 RUNNING 

17. app. state = ApplicationState. RUNNING 

18. } 

19. } 





© 


要 启 


从 上 面 的 代码 中 可 以 看 到 ， 在 for 循环 中 ， 调 用 了 launchExecutor (worker,exec) 方法 ， 
这 个 方法 有 两 个 参数 ， 第 一 个 参数 是 满足 条 件 的 WorkerInfo 信息 ， 第 二 个 参数 是 描述 Execu- 








tor 的 ExecutorDesc 对 象 。 这 个 方法 将 会 向 Worker 结 点 发 送 LaunchExecutor 的 请 求 。 
chExecutor 代码 清单 如 下 所 示 。 


private def launchExecutor( worker: WorkerInfo ,exec:ExecutorDese) :Unit = | 


中 


logInfo("Launching executor " + exec. fullld + " on worker " + worker. id ) 


1 

2 

3 [向 WorkerInfo 中 加 入 exec 这 个 描述 Executor 的 eExecutorDesc 对 象 
4. worker. addExecutor( exec ) 
SS 

6. 





// 问 worker 发 送 LaunchExecutor 消息 ,加 载 Executor 











laun- 


// 消 息 中 携带 了 masterUzl 地 址 application id 、Executor id 、Executor 描述 desc 、Executor 核 





的 个 数 和 Executor 分 配 的 内 存 大 小 
gk worker. endpoint. send( LaunchExecutor( masterUr!l, 


8. exec. application. id ,exec. id ,exec. application. desc ,exec. cores ,exec. memory ) ) 








9. [人 向 Driver 发 回 ExecutorAdded 消息 ,消息 携带 worker 的 id 号 ,worker 的 host 和 port, 以 及 


分 配 的 核 的 个 数 和 内 存 大 小 


10. exec. application. driver. send( 
11. ExecutorAdded ( exec. id , worker. id ,worker. hostPort, exec. cores ,exec. memory ) ) 
12. 1 
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上 面 代码 中 ，launchExecutor 有 两 个 参数 ， 第 一 个 参数 是 worker: WorkerInfo， 代 表 着 
Worker 的 基本 信息 ， 第 二 个 参数 是 exec :ExecutorDesc， 这 个 参数 保存 了 Executor 的 基本 配 
置信 息 ， 如 memory、cores 等 。 此 方法 中 ， 有 worker endpoint. send ( LaunchExecutor 

















(... ) ) ， 这 句 代 码 的 意图 很 明显 ， 即 向 Worker 发 送 LaunchExecutor 请 求 ，Worker 收 到 该 请 
求 之 后 将 会 调用 方法 启动 Reno 

问 Worker 发 送 LaunchExecutor 消息 的 同时 ， 通 过 exec. application. driver ! ExecutorAdded 
向 Driver 发 送 ExecutorAdded 消息 ， 向 Driver 回馈 Master 都 在 哪些 Worker 上 启动 了 Executor， 
Executor 的 编号 是 多 少 ， 为 每 个 Executor 分 配 了 多 少 个 核 、 多 大 的 内 存 ， 以 及 Worker 的 联系 
hostport 等 消息 。 

Worker 收 到 LaunchExecutor 消息 会 做 哪些 事情 呢 ? 从 源 代 码 中 就 能 找到 答案 ， 在 Work- 
er 结 点 中 ，LaunchExecutor 处 理 逻 辑 的 源 代 码 如 下 所 示 。 











1. case LaunchExecutor( masterUzl ,appId ,execId ,appDesc ,cores_ ,memory_ ) => 
2 // 敬 masterUrl 和 activeMasterUrl 不 是 同一 个 url, 说 明 非 法 的 Master 尝试 加 载 Execu- 
tor, 打印 错误 信息 















































3 if (masterUrl | = activeMasterUrl) | 

4 logWarning( " Invalid Master (" +masterUrl + " ) attempted to launch executor. " ) 
5 | else | 

6. try | 

区 // 在 workDir/appId/ 目 录 下 创建 以 execld 为 名 的 Executor 工作 目录 
8 val executorDir = new File( workDir,appld + "/" +execld) 

9 // 调 用 mkdirs 创建 目录 

10. if (lexecutorDir. mkdirs( ) ) | 

11. throw newIOException( " Failed to create directory " + executorDir) 
| 

13. // 为 Executor 创建 本 地 目录 ,该 目录 通过 变量 SPARK_EXECUTOR_DIRS 设置 并 传递 ， 
该 目录 在 Application 运行 结束 时 由 Worker 负责 删除 

14. val appLocalDirs = appDirectories. get( appId). getOrElse | 

15. Utils. getOrCreateLocalRootDirs( conf). map | dir => 

16. // 名 字 前 缀 为 executor 

[gk val appDir = Utils. createDirectory( dir, namePrefix = " executor" ) 
18. // 更 改 文件 目录 权限 为 700 

19. Utils. chmod700(appDir) 

20. // 获 取 绝对 路 径 

2 appDir. getAbsolutePath( ) 

22 }. toSeq 

2 } 

24. // 在 喻 希 表 appDirectories 中 加 入 appld 和 appLocalDirs 的 对 应 关系 
23: appDirectories( appId) = appLocalDirs 

26. // 创 建 ExecutorRunner 

2 val manager = new ExecutorRunner( 


28. appld , execld, 
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29. appDesc. copy ( command = Worker. maybeUpdateSSLSettings ( appDesc. command ， 
conf ) ) , cores_, memory_, self, workerld, host, webUi. boundPort, publicAddress, spark Home, execu- 


torDir ,workerUri ,conf,appLocalDirs ,ExecutorState. RUNNING) 















































30. // 在 哈 希 表 executors 中 加 入 appld +"Z" + execId 和 ExecutorRunner 的 对 应 关系 O) 
31. executors( appld + "/" +execld) = manager 
22 // 启 动 ExecutorRunner 
33. manager. start( ) 
34. //Worker 上 已 经 使 用 的 核 增 加 cores_ 个 ,cores_ 为 分 配给 Executor 的 核 的 个 数 
Ss coresUsed += cores_ 
36. /A/Worker 上 已 经 使 用 的 内 存 增 加 memeory_,memeory 为 分 配给 Executor 的 内 存 
3 memoryUsed += memory_ 
38. // 问 Master 发 送 ExecutorStateChanged 消息 ,该 消息 携带 appld ,exeld, Executor- 
Runner 的 状态 
39. sendToMaster( ExecutorStateChanged ( appld ,execId ,manager. state, None, None ) ) 
40. } 
41.1 
从 上 面 的 代码 中 可 以 看 到 ， 首 先 判 断 传 过 来 的 masterUrl 是 否 与 activeMasterUrl 相同 ， 如 
果 不 相 同 , 说明 收 到 的 不 是 处 于 ALIVE 状态 的 Master 发 送 过 来 的 请 求 ， 这 种 情况 下 直接 打 
印 警 告 信息 ;如 果 相同 ， 则 说 明 该 请 求 来 自 ALIVE Master， 于 是 为 Executor 创建 工作 目录 ， 


创建 好 工 


作 目 录 之 后 ， 使 用 appId 、execld 和 appDes 等 参数 创建 ExecutorRunner。 顾 名 思 义 ， 








ExecutorRunner 是 Executor 运行 的 地 方 ， 在 ExecutorRunner 中 ， 有 一 个 工作 线程 ， 这 个 线程 


负 由 责 下 载 
启动 的 源 


在 上 





依赖 的 文件 ， 并 启动 CoarseGaindExecutorBackend。 下 面 是 ExecutorRunner 中 的 线程 









































代码 。 

1. private[ worker] def start( ) |//ExecutorRunner 的 start 方法 

2 // 创 建 线程 

3. workerThread = new Thread( "ExecutorRunner for " +fullld) | 

4. // 在 线程 run 方法 中 调用 fetchAndRunExcutor 

Se, override def run( ) |fetchAndRunExecutor( ) | 

6. } 

7. ”// 启 动 线程 

8. workerThread. start( ) 

9. /终止 回调 函数 ,用 于 杀 死 进程 

10. shutdownHook = ShutdownHookManager. addShutdownHook | () => 
11. if (state == ExecutorState. RUNNING) | 

2 state = ExecutorState. FAILED 

13. } 

14. killProcess( Some(" Worker shutting down" ) ) |) 

| 

面 的 代码 中 ， 定 义 了 一 个 Thread ， 这 个 Thread 的 run 方法 中 调用 fetchAndRunExec- 








utor 方法 ， 负 责 上 
CoarseGrainedExecutorBackend。fetchAndRunExecutor 方法 的 源 代 码 如 下 所 示 。 
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进程 的 方式 启动 ApplicationDescription 中 携带 的 org. apache. spark. executor. 


1. private def fetchAndRunExecutor( ) | 


2 
3 
4. 


try | 
// 使 用 CommandUtils 创建 ProcessBuilder 


Val builder = CommandUtils. buildProcessBuilder ( appDesc. command , new SecurityManager 




















(conf) ,memory ,spark Home. getAbsolutePath ,substituteVariables ) 


S$ 


11. 


// 得 到 进程 启动 命令 
val command = builder. command( ) 
// 格 式 化 启动 命令 
val formattedCommand = command. asScala. mkString(" \"","\" \"","\"") 
logInfo( s" Launch command: $ formattedCommand" ) 
// 设 置 进程 工作 目录 
builder. directory ( executorDir) 
// 在 进程 环境 变量 中 加 入 SPARK_EXECUTOR_DIRS 工作 目录 


13. builder. environment. put( "SPARK_EXECUTOR_DIRS" ,appLocalDirs. mkString 
( File. pathSeparator ) ) 




















14. // 在 进程 环境 变量 中 加 入 SPARK_LAUNCH_WITH_SCALA 

Is» builder. environment. put(" SPARK_LAUNCH_WITH_SCALA","0") 

16. /A/Web 日 志 的 wl 

17. val baseUrl = 

18. s" http:// $ publicAddress: $ webUiPort/logPage/? appld = $ appld&executorld = $ 
execld&logType =" 

19. builder. environment. put(" SPARK_LOG_URL,_STDERR" ,s" $ |baseUrl| stderr" ) 
20. builder. environment. put( "SPARK_LOG_URL_STDOUT" ,s" $ |baseUrl} stdout" ) 
2 用 // 启 动 CoarseGrainedExecutorBackend 进程 

2 process = builder. start( ) 

23 val header = " Spark Executor Command:% s\n% s\n\n". format( 

24. formattedCommand," =" *40) 

2 val stdout = new File( executorDir, " stdout" ) 

26. stdoutAppender = FileAppender( process. getInputStream ,stdout , conf) 

2 val stderr = new File( executorDir ," stderr" ) 

28. Files. write( header, stderr, UTF_8) 

29. stderrAppender = FileAppender( process. getErrorStream ,stderr , conf ) 

30. // 等 待 进程 退出 

31. val exitCode = process. waitFor( ) 

3 state = ExecutorState. EXITED 

33. val message = " Command exited with code " +exitCode 

34. //Executor 进程 退出 后 向 Worker 发 送 ExecutorStateChanged 消息 ,Worker 收 到 该 消息 后 


回收 分 配给 该 Executor 的 cores 和 memory 


35. 





worker. send ( ExecutorStateChanged ( appld ,execld , state, Some( message ) , Some( exitCode ) ) ) 
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CoarseGrainedExecutorBackend 启动 后 ， 会 首先 通过 传人 的 driverUzl 这 个 参数 向 DriverAc- 
tor 发 送 RegisterExecutor (executorld, self, hostPort , cores, extractLogUrls ) ，Driver 收 到 此 消息 
后 ， 登 记 注册 好 的 Executor 信息 ， 并 回复 RegisteredExecutor ，CoarseGrainedExcutorBackend 收 
到 RegisteredExecutor 消息 后 ， 创 建 org. apache. spark. executor. Executor ， 至 此 ，Executor 创建 





完毕 。 
区 | Executor 的 资源 分 配 ] 
Executor 作为 单独 的 进程 运行 于 Worker 结 过 图 5-1 可 以 清楚 地 看 到 ， 当 Exec- 


utorRunner 启动 CoarseGrainedExecutorBackend 0 CoarseGrainedExecutorBackend 中 会 
先 向 Driver 发 送 RegisterExecutor 请 求 ， 完 成 注册 。 如 果 注 册 成 功 ， 返 回 RegisteredExecutor 消 
息 ，CoarseGrainedExecutor 收 到 该 消息 并 新 建 Executor。 如 果 注 册 失 败 ， 返 回 RegisterExecu- 
torFailed 消息 ，CoarseGrainedExecutorBackend 进程 退出 。 

CoarseGrainedExecutorBackend 此 时 以 进程 的 形式 启动 ， 运 行 于 一 个 独立 的 JVM 中 。 编 
写 过 Java 程序 的 人 都 知道 ， 在 启动 JVM 时 ， 可 以 通过 java - server 配置 项 为 JVM 分 配 堆 栈 
大 小 , 因此 ， 此 处 ProcessBuilder 启动 的 CoarseGrinedExecutorBackend 进程 也 可 以 通过 类 似 的 
命令 配置 JVM 的 堆栈 大 小 ,那么 这 些 堆栈 的 大 小 是 如 何 设置 的 呢 ? 

Executor 运行 在 一 个 单独 的 进程 中 ， 必 然 会 涉及 资源 的 分 配 问题 ， 也 可 以 像 运行 Java 程 
序 一 样 ， 在 启动 进程 时 ， 为 其 分 配 资源 。 在 Spark 中 ， 可 以 通过 指定 配置 参数 的 形式 ， 为 
Executor 配置 运行 资源 ， 例 如 ， 可 以 指定 每 一 个 Executor 占用 内 存 的 大 小 、 运 行 核 的 个 数 
等 表 5-1 所 示 是 Executor 的 一 些 配 置 参数 。 


表 S$-1 Executor 配置 参数 





















































参数 名 称 默 认 值 描 述 
spark. executor. memory lg 为 Executor 分 配 的 内 存 大 小 
spark. executor extraJavaOptions none 传递 给 Executor 的 JVM 选项 ， 如 GC 设置 、Heap 设置 等 
spark. executor extraLibraryPath none 指定 启动 Executor JVM 时 依赖 的 库 路 径 
spark. executor. logs. rolling. maxSize none 设置 Executor 日 志 滚 动 的 大 小 
本 [ EnvironmentVari- 二 为 Executor 指定 环境 变量 
ee 1 或 所 有 Executor 占用 核 的 个 数 ，Yamn 模式 默认 占用 一 个 ，Standa- 
lone 默认 使 用 所 有 核 
spark. executor heartbeatInterval 10s 向 Driver 发 送 心 跳 的 时 间 间 隔 
spark. executor port random Executor 监控 的 端口 ， 用 于 和 Driver 通信 
spark. dynamicAllocation. maxExecutors 无 穷 动态 分 配 Executor 的 最 大 个 数 
spark. dynamicAllocation. minExecutors 0 动态 分 配 Executor 的 最 小 个 数 

















Sm 
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Executor 的 这 些 配置 项 可 以 有 多 种 不 同 的 配置 方式 ， 例 如 ， 可 以 在 系统 环境 变量 中 指定 
spark. executor. memory 的 大 小 ， 也 可 以 在 配置 文件 spark -env. sh 中 指定 spark. executor. memory 
的 大 小 ， 最 常用 的 方式 是 在 使 用 spark - submit 提交 程序 时 ， 通 过 参数 指定 Executor 的 配置 ， 























如 果 不 指定 Executor 的 配置 ， 将 使 用 默认 值 。 
通过 spark - submit 指定 Executor 参数 ， 可 以 使 用 如 【 例 $-1】 所 示 的 参数 提交 程序 。 
【 例 5-1】 spark - submit 中 Executor 参数 的 指定 。 





1. ./bin/spark - submit \ 

2 —— class org. apache. spark. examples. SparkPi \ 

3 —— master spark://207. 184. 161. 138 :7077 \ 

4. 一 -executor - memory 20G \”// 指 定 Executor 运行 内 存 
S 一 一 total - executor - cores 100\ // 指 定 Executor 运行 内 核 的 个 数 
6. /path/to/examples. jar \ 

7 


1000 





【 例 S-1】 中 ， 通 过 - - executor - memory 指定 Executor 内 存 大 小 为 20GB， 有 可 执行 的 
内 核 的 个 数 为 100 个 。 

这 些 配置 的 参数 是 如 何 传递 给 CoarseGrainedExecutorBackend， 并 以 这 些 传递 过 来 的 参数 
启动 JVM 进程 呢 ? 首先 来 看 一 下 在 程序 中 是 如 何 接收 这 些 命令 行 参数 的 。 
查看 spark - submit 脚本 ， 脚 本 中 直接 运行 了 org. apache. spark. deploy. SparkSubmit 这 个 
对 象 。spark - submit 脚本 的 内 容 如 下 所 示 。 




















1. #! /usr/bin/env bash 

2. SPARK_HOME=" $ (cd" diname "$0" "/.. ;pwd)" 

3. export PYTHONHASHSEED =0 

4. exec " $ SPARK_ HOME"/bin/spark - class org. apache. spark. deploy. SparkSubmit " $ @ "// 运 
行 SparkSubmit 


进入 到 SparkSubmit 中 ，main 函数 的 代码 如 下 所 示 。 


1. def main( args:Array[ String| ) :Unit = | 

2 // 由 启动 main 函数 传人 的 参数 构建 SparkSubmitAruments 对 象 
3 val appArgs = new SparkSubmitArguments( args) 

4. /打印 参数 信息 
S$: if (appArgs. verbose) | 
6 

7 

8 

9 





printStream. println( appArgs) 


| 


appArgs. action match | 





// 提 交 , 调 用 submit 方法 
10. case SparkSubmitAction. SUBMIT => submit( appArgs) 
11. // 杀 死 , 调 用 kill 方法 
2 case SparkSubmitAction. KILL => kill(appArgs) 
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US // 请 求 状态 ,调用 requestStatus 方法 
14. case SparkSubmitAction. REQUEST_STATUS => requestStatus( appArgs) 
|S } 


16 | > 


上 面 代码 中 ，spark - submit 脚本 提交 的 命令 行 参数 通过 main 函数 的 args 获取 ， 并 将 
args 参数 传人 SparkSubmitArguments 中 解析 最 后 通过 匹配 appArgs 参数 中 的 action 类 型 
执行 submit 、Kkill 和 requestStatus 操作 。 

进入 到 SparkSubmitArguments 中 ， 分 析 一 下 参数 的 解析 过 程 。SparkSubmitArguments 中 的 
关键 代码 如 下 所 示 。 














1. // 调 用 parse 方法 ,从 命令 行 中 解析 出 各 个 参数 

2 try | 

3 parse( args. asJava) 

4 | catch | 

3 // 捕 获 到 IllegalArgumentException ,打印 错误 并 退出 
0 case e:llegalArgumentException => 

有 SparkSubmit. printErrorAndExit( e. getMessage( ) ) 

8 | 

9 // 合 并 默认 的 Spark 配置 项 ,使 用 传人 的 配置 覆盖 默认 的 配置 
10. mergeDefaultSparkProperties( ) 

11. ”// 从 sparkProperties 移 除 不 是 以 “spark. ”为 开始 的 配置 
12 ignoreNonSparkProperties( ) 

13. /加 载 系统 环境 变量 中 的 配置 信息 

14. loadEnvironmentArguments( ) 

15.， /验证 参数 是 否 合 

16. val idateArguments( ) 






























































在 上 面 的 代码 中 ，parse (args. toList) 将 会 解析 命令 行 参 数 ， 通 过 mergeDefaultSpark- 
Properties 合并 默认 配置 ， 调 用 ignoreNonSparkProperties 方法 忽略 不 是 以 “spark. ”为 开始 的 
配置 ， 方 法 加 载 系统 环境 变量 ， 最 后 调用 validateArguments 方法 检 
验 参 数 的 合法 性 。 这 些 配置 如 何 提交 呢 ? main 函数 中 有 case SparkSubmitAction. SUBMIT => 
submit (appArgs) ， 这 句 代 码 判 断 是 否 提交 参数 并 执行 程序 ， 如 果 匹 配 到 SparkSubmitAction. 
SUBMIT， 则 调用 submit ( appArgs ) 方法 ， 参 参数 appArgs 是 SparkSubmitArguments 类 型 ， ap- 
pArgs 中 包含 了 提交 的 各 种 参数 ， 包 括 命 令 行 传人 及 默认 的 配置 项 。 

submit (appArgs) 方法 主要 完成 以 下 两 件 事情 。 

1) 准备 提交 环境 ， 

2) 执行 main 方法 完成 提交 。 

首先 看 一 下 在 Spark 中 是 如 何 准备 环境 的 。 在 submit (appArgs) 方法 中 ， 有 以 下 源 
代码 。 












































1. val (childArgs,childClasspath ,sysProps ,childMainClass) = prepareSubmitEnvironment( args ) 
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在 这 段 代 码 中 ， 调 用 prepareSubmitEnvironment (args) 方法 完成 提交 环境 的 准备 。 该 方 
法 返回 一 个 四 元 Tuple， 分 别 表 示 子 进程 参数 、 子 进程 classpath 列表 、 系 统 属性 map 和 子 进 
程 main 方法 。 完 成 了 提交 环境 的 准备 工作 之 后 ， 接 下 来 将 启动 子 进 程 ， 在 Standalone 模式 
下 ， 启动 的 子 进 程 是 org. apache. spark. deploy. Client 对 象 。 具 体 执行 过 程 在 rnMain 函数 中 
关键 代码 如 下 所 示 。 











1. private def runMain( 

多 childArgs:Seq[ String | ， 

3 childClasspath :Seq[ String | ， 

4 sysProps: Map[ String, String | ， 
3 childMainClass: String, 
6 

% 

8 

9 


verbose: Boolean) :Unit = | 


Thread. currentThread. setContextClassLoader( loader)// 获 得 classLoader 
for (jar < 一 childClasspath) | /遍历 classpath 列表 























10. addjJarToClasspath(jar,loader)// 使 用 loader 类 加 载 器 将 jar 包 依赖 加 入 classpath 
11. 

| for ( (key,value) <-sysProps) 1// 将 sysProps 中 的 配置 全 部 设置 到 System 全 局 变量 中 
13. System. setProperty( key , value) 

14. | 

I var mainClass:Class[ _|] = null 


16. mainClass = Utils. classForName( childMainClass ) /获取 启动 的 MainClass 
17. …// 得 到 启动 的 对 象 的 main 方法 
18. val mainMethod = mainClass. getMethod( "main" ,new Array[ String | (0). getClass ) 
19. …// 使 用 反射 执行 main 方法 ,并 将 childArgs 作为 参数 传人 该 main 方法 
20. mainMethod. invoke( null , childArgs. toArray ) 

21. | 


























在 上 面 的 代码 中 ,使 用 Utils 工具 提供 的 classForName 方法 找到 主 类 ， 然 后 在 mainClass 
上 调用 getMethod 方法 得 到 main 方法 ， 最 后 在 mainMethod 上 调用 invoke 执行 main 方法 。 需 
要 注意 的 是 ， 执 行 invoke 方法 的 同时 传人 了 childArgs 参数 ， 这 个 参数 中 保留 了 配置 信息 。 
Utils. classForName (childMainClass) 方法 将 返回 要 执行 的 主 类 ， 这 里 的 childMainClass 是 哪 
一 个 类 呢 ? 其 实 这 个 参数 在 不 同 的 部 署 模式 下 是 不 一 样 的 ，standalone 模式 下 ，childMain- 
Class 指 的 是 org. apache. spark. deploy. Client 这 个 类 ， 从 源 代码 中 可 以 找到 依据 ， 源 代码 如 下 
所 示 。 























// 在 prepareSubmitEnvironment 方法 中 判断 是 否 为 Standalone 集群 模式 
if (args. isStandaloneCluster) | 
// 判 断 使 用 Rest childMainClass 为 org. apache. spark. deploy. rest. RestSubmissionClient 
if (args. useRest) | 
childMainClass = " org. apache. spark. deploy. rest RestSubmissionClient" 


childArgs += (args. primaryResource,args. mainClass) 
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| else | 
// 非 Rest,childMainClass 为 org. apache. spark. deploy. Client 
childMainClass = " org. apache. spark. deploy. Client" 
if (args. supervise) |childArgs += " —— supervise" | OO 
// 设 置 driver memory 





Option( args. driverMemory). foreach | m => childArgs += (" -~—-memory",m) | 
// 设 置 driver cores 

Option( args. driverCores). foreach | e => childArgs += (" ——cores",c) | 
childArgs += "launch" 

childArgs += (args. master,args. primaryResource,args. mainClass) 


| 
if (args. childArgs ! = null) | 
childArgs + += args. childArgs 


| 

















在 上 面 的 代码 中 ， 程 序 首 先 根据 args. isStandaloneCluster 判断 部 署 模式 ， 如 果 是 Standa- 
lone 模式 并 且 不 使 用 REST 服务 ，childMainClass = " org. apache. spark. deploy. Client" 。 上 述 代 
码 中 ， 可 以 看 出 childArgs 中 存 人 了 Executor 的 memory 配置 和 cores 配置 。 如 runMain 方法 中 
描述 的 一 样 ， 程 序 将 启动 org. apache. spark. deploy. Client 这 个 类 ， 并 运行 主 方法 ，Client 类 
中 做 了 哪些 事情 ， 先 来 看 一 下 这 个 类 中 是 如 何 完成 调用 的 。 下 面 是 Client 对 象 及 主 方法 。 











1. object Client | 

2 def main( args: Array| String]) | 

// 蔡 sys 中 不 包含 SPARK_SUBMIT ,打印 警告 信息 
4 

5 





if (1! sys. props. contains( "SPARK_SUBMIT" ) ) | 
println( " WARNING.: This client is deprecated and will be removed in a future version of 





Spark" ) 

6. // 打 印 提示 信息 

I println( " Use . /bin/ spark - submit with \" —— master spark://host:port\"") 
8. 





9. // 创 建 SparkConf 对 象 
10. val conf =new SparkConf( ) 
11. // 创 建 ClientArguments 对 象 ,代表 Driver 端的 参数 








| val driverArgs = new ClientArguments( args) 

下 5 if (!driverArgs. logLevel. isGreaterOrEqual( Level. WARN) ) | 
14. conf set( "spark. akka. logLifecycleEvents" , "true" ) 

1s: } 

16. // 设 置 RPC 请 求 超时 时 间 为 10s 

(98 conf set( " spark. rpc. askTimeout" ,"10" ) 

18. // 设 置 Akka 的 日 志 级 别 ,使 用 WARNING 代 蔡 WARN 


19. conf set(" akka. loglevel" , driverArgs. logLevel. toString. replace(" WARN" ," WARNING" ) ) 
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20. Logger. getRootLogger. setLevel( driverArgs. logLevel ) 
21. // 使 用 RpcEnv 的 create 创建 Rpc 环境 
225 val rpcEnv = 


23. RpcEnv. create( "driverClient" , Utils. localHostName( ) ,0 ,conf, new SecurityManager( conf) ) 

24. /得 到 master 的 ul 并 得 到 Master 的 Endpoints ,用 于 与 Master 通信 

25. val masterEndpoints = driverArgs. masters. map( RpcAddress. fromSparkURL). 

26. map(rpeEnv. setupEndpointRef( Master. SYSTEM_NAME,_, Master. ENDPOINT_NAME) ) 
27.// 使 用 RpeEvwn 的 setupEndpoint 方法 设置 名 为 client 的 Endpoint ,该 Endpoint 可 以 与 Master 




















28. rpcEnv. setupEndpoint( "client" ,new ClientEndpoint(rpeEnv ,driverArgs ,masterEndpoints ,conf) ) 
29.， /等 待 rpcEnv 的 终止 

30. rpeEnv. awaitTermination( ) 

| 
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上 面 代码 中 ， 首 先 实例 化 出 一 个 SparkConfig 对 象 ， 通 过 这 个 配置 对 象 ， 可 以 在 代码 中 
指定 一 些 配 置 项 ， 如 appName 、Master 地 址 等 。val driverArgs = new ClientArguments (args ) 
使 用 传人 的 args 参数 构建 一 个 ClientArguments 对 象 ， 该 对 象 同样 保留 传人 的 配置 信息 ， 上 x- 
ecutor memory、 Executor cores 等 都 包含 在 这 个 对 象 中 。 

上 面 代码 的 第 22 行 ， 使 用 RpcEnv. create 工厂 方法 创建 一 个 rpcEnv 成 员 ， 使 用 该 成 员 
设置 好 到 Master 的 通信 端点 ， 通 过 该 端点 实现 与 Master 的 通信 。Spark 之 前 版 本 采用 Akka 
框架 来 实现 Rpe 远程 过 程 调用 ， 通 过 使 用 Akka 的 分 布 式 异步 通信 机 制 ， 完 成 各 结 点 之 间 的 
通信 。 这 里 通过 masterEndpoint 向 Master 发 送 RequestSubmitDriver (〈 driverDescription ) 请 求 ， 
完成 Driver 的 注册 。 

代码 中 提交 的 配置 参数 始终 在 不 同 的 对 象 和 结 点 上 传递 。Master 把 Driver 加 载 到 Worker 
结 点 并 启动 起 来 ，Worker 结 点 上 运行 的 Driver 同样 包含 配置 参数 。 当 Driver 端的 SparkContext 
启动 并 实例 化 DAGScheduler、TaskScheduler 时 ，TaskSchedulerBackend 在 做 另 一 件 事 情 ， 即 实 
例 化 AppClient，AppClient 中 有 AppClientPoint， 用 于 通信 。AppClientPoint 的 onStart 方法 中 ， 
向 Master 发 送 RegisterApplication (appDescription, self) 请 求 ，Master 结 点 收 到 请 求 并 调用 
schedule 方 法， 向 Worker 发 送 LaunchExecutor ( masterUrl ，exec. application. id ，exec. id ， 
exec. application. desc ,exec. cores ,exec. memory) 请 求 ，Worker 结 点 启动 ExecutorRunner，Execu- 
torRunner 启动 CoarseGrainedExecutorBackend 并 向 Driver 注册 。 

在 CoarseGrainedExecutorBackend 的 main 方法 中 ， 有 如 下 所 示 的 代码 。 


























1. ”var argv = args. toList// 将 args 转化 成 List 

2 while (1 argv. isEmpty) |//argv 不 为 空 , 则 一 直 循 环 
3 argv match | 

4. case (" ——driver —url") ::value ::tail => 

3 driverUrl = value// 得 到 Driverurl 

6 argv = tail 

% case (" ——executor -id" ) ::value ::tail => 
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8. executorld = value// 得 到 executor id 

中) argv = tail 

10. case (" ——hostname" ) : :value ::tail => 

11. hostname = value// 得 到 hostname O) 
jl argv = tail 

bs case (" ——cores") ::value ::tail => 

14. cores = value. toInt// 得 到 配置 的 Executor 核 的 个 数 

15. Sargv = tail 

16. case (" ——-app—id") ::value ::tail => 

17. appId = value// 得 到 application 的 id 

18. argv = tail 

19. case (" ——worker— url") ::value ::tail => 

20. workerUrl = Some( value )// 得 到 worker 的 ul 

2 argv = tail 

2 case (" ——user—class —path") ::value ::tail => 

238 userClassPath += new URL(value)// 得 到 用 户 类 路 径 
24. argv = tail 

23 case Nil => 

26. case tail => 

2 的 System. err. println( s" Unrecognized options: $ |tail. mkString(" " )}") 
28. printUsageAndExit( )// 打 印 并 退出 

29. } 

30. } 


从 程序 提交 一 直到 CoarseGrainedExecutorBackend 进程 启动 ， 配 置 参 数 一 直 被 传递 。 在 
CoarseGrainedExecutorBackend 中 取出 了 内 核 配 置信 息 ， 并 通过 run (driverUrl，executorld， 
hostname ，cores，applId，workerUrl，userClassPath) 将 该 配置 信息 传人 run 方法 ， 此 时 Coar- 
seGrainedExecutorBackend 以 进程 的 形式 在 JVM 中 启动 ，JVM 以 占用 指定 核 的 个 数 启动 起 来 。 
需要 注意 的 是 ， 在 一 个 Worker 结 点 上 ， 只 要 处 理 内 核 的 个 数 满 足 Executor 启动 要 求 ， 一 个 
Worker 结 点 上 可 以 运行 多 个 Executor。 




















Executor 的 启动 


在 5.1.2 节 中 ， 了 解 了 参数 的 传递 过 程 和 外 部 配置 的 参数 ， 通 过 结 点 之 间 的 消息 传递 ， 
最 终 作 用 在 Executor 上 ， 外 部 配置 的 参数 终 将 会 在 Executor 上 发 挥 作用 。 在 本 节 中 ， 主 要 探 
讨 Executor 的 启动 过 程 。 

再 回 到 SparkDeploySchedulerBackend 上 来 ， 在 SparkDeploySchedulerBackend 中 会 新 建 
AppClient，AppClient 启动 后 会 向 Master 发 送 RegisterApplication 消息 ，Master 在 收 到 Regis- 
terApplication 请 求 后 ， 将 会 调用 schedule 方法 ， 在 调度 过 程 中 会 使 用 allocateWorkerResource- 
ToExecutors 方法 为 Worker 结 点 上 的 Executor 分 配 资源 。 分 好 资源 后 ， 调 用 launchExecutor 
(worker,exec) 方法 ， 此 方法 将 向 Worker 发 送 LaunchExecutor 请 求 ， 启 动 Executor。 下 面 是 
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launchExecutor 方法 的 源 代码 。 


1. private def launchExecutor( worker: WorkerInfo, exec: ExecutorDesc) :Unit = | 

2 logInfo( " Launching executor " + exec. fullld + " on worker " + worker. id) 

3 [向 WorkerInfo 中 加 入 exec 这 个 描述 Executor 的 eExecutorDese 对 象 

4. worker. addExecutor( exec ) 

5 // 问 worker 发 送 LaunchExecutor 消息 ,加载 Executor 

6. // 消 息 中 携带 了 masterUzl 地 址 application id 、Executor id 、Executor 描述 desc 、Executor 核 
的 个 数 和 Executor 分 配 的 内 存 大 小 











外 worker. endpoint. send( LaunchExecutor( masterUzl ， 

8. exec. application. id ,exec. id ,exec. application. desc ,exec. cores ,exec. memory ) ) 

9. // 问 Driver 发 回 ExecutorAdded 消息 ,消息 携带 worker 的 id 号 , Worker 的 host 和 
port, 以 及 分 配 的 核 的 个 数 和 内 存 大 小 

10. exec. application. driver. send( 

i ExecutorAdded ( exec. id, worker. id , worker. hostPort ,exec. cores ,exec. memory ) ) 

12. | 


launchExecutor 方法 中 会 向 Worker 发 送 LaunchExecutor 消息 ， 先 来 看 一 看 LaunchExecutor 
消息 的 几 个 参数 ，masterUrl 是 集群 中 master 的 Url，exec. application. id 是 Master 为 Applica- 
tion 分 配 的 id 号 ,该 id 号 在 注册 Application 时 就 已 经 生成 好 了 。exec. id 是 Executor 的 id 
号 ，Master 在 为 Application 分 配 Worker 时 该 id 号 就 已 经 指定 好 。exec. application. desc 是 ap- 
plication 的 描述 ， 包 括 name 、maxCores 、memoryPerExecutorMB 、command 、appUiUrl 和 even- 
tLogDir 等 信息 。exec. cores 、exec. memory 分 别 代 表 Executor 运行 核 

Worker 收 到 LaunchExecutor 消息 后 ， 首 先 启 动 ExecutorRunner ， 然 后 向 Master 发 送 Exec- 
utorStateChanged (appld ,execId ,manager. state,None,None) 消息 ，Master 在 收 到 此 消息 后 将 
视 Executor 的 状态 调用 schedule( ) 方 法 ， 重 新 调整 集群 资源 。 

ExecutorRunner 启动 后 ， 将 调用 fetchAndRunExecutor 方法 创建 Executor 工作 目录 并 启动 
CoarseGraindExecutorBancked 进程 ，fetchAndRunExecutor 方法 的 源 代 码 如 下 所 示 。 




















private def fetchAndRunExecutor( ) | 


try | 
// 使 用 CommandUtils 创建 ProcessBuilder 

















1 

史 

3 

4 Val builder = CommandUtils. buildProcessBuilder( appDesc. command ,new SecurityManager 
(conf) ,memory ,spark Home. getAbsolutePath ,substituteVariables ) 

5. // 得 到 进程 启动 命令 

6 val command = builder. command( ) 

7 // 格 式 化 启动 命令 

8 val formattedCommand = command. asScala. mkString(" \"","\" \"","\"") 
9. logInfo( s" Launch command: $ formattedCommand" ) 

10. /设置 进程 工作 目录 

11. builder. directory ( executorDir ) 

12. // 在 进程 环境 变量 中 加 入 SPARK_EXECUTOR_DIRS 工作 目录 
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13. builder. environment. put ( " SPARK _ EXECUTOR _ DIRS" , appLocalDirs. mkString 
(File. pathSeparator ) ) 

14. // 在 进程 环境 变量 中 加 入 SPARK_LAUNCH_WITH_SCALA 

[ss builder. environment. put(" SPARK_LAUNCH_WITH_SCALA","0") 

16. //Web 日 志 的 wl 

hs valbaseUrl = 

18. s"http://$ publicAddress: $ webUiPort/logPage/? appld = $ appld&executorld = $ 
execld&logType =" 

19. builder environment. put(" SPARK_LOG_URL,_STDERR" ,s" $ | baseUrl| stderr" ) 

20. builder environment. put( "SPARK_LOG_URL,_STDOUT" ,s" $ | baseUrl| stdout" ) 

2 // 启 动 CoarseGrainedExecutorBackend 进程 

2 process = builder. start( ) 

3 val header ="Spark Executor Command :% s\n% s\n\n". format( 

24. formattedCommand," =" *40) 

2 val stdout = new File( executorDir, " stdout" ) 


26. stdoutAppender = FileAppender( process. getInputStream ,stdout , conf ) 





2 val stderr = new File( executorDir ," stderr" ) 

28. Files. write( header, stderr, UTF_8) 

29. stderrAppender = FileAppender( process. getErrorStream , stderr, conf ) 

30. // 等 待 进程 退出 

31. val exitCode = process. waitFor( ) 

32: state = ExecutorState. EXITED 

3 val message = " Command exited with code " +exitCode 

34. //Executor 进程 退出 后 向 Worker 发 送 ExecutorStateChanged 消息 , Worker 收 到 该 消 
息 后 回收 分 配给 该 Executor 的 cores 和 memory 

35. worker. send ( ExecutorStateChanged ( appld, execld, state, Some ( message ) , Some ( exit- 
Code) ) ) 

36. } 
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在 上 面 代码 中 的 第 4 行 ， 使 用 CommandUtils 工具 构建 了 一 个 ProcessBuilder， 构 建 Process- 
Builder 时 传人 了 appDesc. command 、memory 、sparkHome. getAbsolutePath 和 substituteVariables 这 
几 个 参数 ， 分 别 代表 命令 、 内 存 大 小 、SparkHome 绝对 路 径 和 替代 参数 。appDesc command 命令 
对 象 里 面包 括 mainClass 、Arguments 、Environment 、classPathEntries 、libraryPathEntries 和 javaOpts 
这 几 项 内 容 。command 中 包含 了 启动 进程 的 关键 配置 项 ， 其 中 mainClass 代表 的 就 是 启动 进程 的 
名 称 ，Standalone 模式 下 mainClass 指 代 的 是 “org. apache. spark. executor. CoarseGrainedExecutor- 
Backend”。Command 的 源 代码 如 下 所 示 。 











1. private[ spark | case class Command( 

多 mainClass: String ,// 启 动 进程 主 类 名 称 

3. arguments :Seq[ String ] ,// 参 数 

4 environment: Map[ String, String] ,// 环 境 变 量 





© 
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classPathEntries :Seq[ String] ,人 类 路 径 
libraryPathEntries :Seql String | ,// 库 路 径 
javaOpts:Seq[ String] ) 1AAJVM 配置 项 


0 


| 





这 些 参数 在 构建 提交 环境 时 就 已 经 准备 好 ， 通 过 ApplicationDescription 传递 过 来 。 上 面 
提 到 的 替代 参数 是 什么 意思 呢 ? 这 还 得 从 部 署 谈 起 。 在 Standalone 模式 下 ，TaskScheduler 启 
动 的 SchedulerBackend 是 SparkDeploySchedulerBackend。SparkDeploySchedulerBackend 会 预先 
构建 Executor 的 一 些 参数 ， 在 构建 这 些 参 数 时 ， 这 些 参 数 的 值 还 没 法 获取 ， 因 此 使 用 了 替代 
参数 ， 在 这 些 参 数 的 值 获取 了 之 后 再 替代 。 在 SparkDeloySchedulerBackend 中 有 以 下 这 些 事 
先 构 建 好 的 替代 参数 ， 源 代码 如 下 所 示 。 














l. val args =Seq( 


2 " —— driver -ur" ,driverUrl ， 

人 " -一 executor -id" ," | |EXECUTOR_ID} }" ,//Executor Id ,在 构建 该 参数 时 , Executor 还 
没有 构建 好 

4. " -一 hostname" ," | |HOSTNAME| }" ,// 主 机 名 称 

5 "一 一 cores" ," | | CORES| }",// 核 的 个 数 

6. A TD 

有 " ——worker —url","||WORKER_URL}| }" )//worker 的 ul 


上 面 代码 中 ,构建 了 一 个 名 为 args 的 序列 。 该 序列 中 包括 driver - wl、executor - 这 、host- 
name 、cores 、app -id 和 worker -url 这 几 个 参数 ， 并 指定 使 用 | |name} | 作为 占 位 符 ， 和 暂时 代替 这 
些 还 没有 具体 值 的 参数 。 这 些 参 数 将 会 在 org. apache. spark. deploy. worker. ExecutorRunner 启动 
CoarseGrainedExecutorBackend 时 被 替换 成 真实 的 值 。 替 换 源 代码 如 下 所 示 。 


1. while (! argv. isEmpty) | 

2 rgv match | 

3 case (" ——driver — url") ::value ::tail => 

4 driverUrl = value 

SE argv = tail 

6 case (" -executor -id" ) : :value ::tail =>// 蔡 换 executor 的 值 
¥ executorld = value 

8 argv = tail 

9 case (" -一 hostname" ) ::value : :tail =>// 替 换 hostname 
10. hostname = value 

11. argv = tail 

12 case (" -一 cores" ) : :value ::tail =>// 蔡 换 cores 

1S cores = value. toInt 

14. argv = tail 

| case (" -app -id" ) ::value ::tail =>// 和 替换 application id 


16. appld = value 
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es argv = tail 

18. case (" —— worker — url" ) : :value : :tail =>// 蔡 换 worker url 
19. workerUrl = Some( value) 

20. argv = tail O) 
21. case (" ——user—class -path" ) :value ::tail => 

2 userClassPath += new URL(value) 

3 argv = tail 

24. case Nil => 

25. case tail => 

26. printUsageAndExit( ) 

2 } 

28. } 


回 过 头 来 看 一 下 前 面 fetchAndRunExecutor 方法 中 的 第 22 行 代码 ，process = build- 
er. start( ) ， 这 人 名 代码 调用 Java 的 ProcessBuilder 的 start 方法 ,依据 传人 的 启动 参数 启动 进 
程 。 在 使 用 CommondUtils 的 buildProcessBuilder 方法 创建 builder 时 ， 传 人 了 启动 进程 的 命 
令 ， 该 命令 已 经 在 SparkDeploySchedulerBackend 中 构建 好 ， 源 代码 如 下 所 示 。 





1. val command = Command( "org. apache. spark. executor. CoarseGrainedExecutorBackend'" ， 
2 args, sc. executorEnvs, classPathEntries + + testingClassPath, libraryPathEntries, jav- 


aOpts) 


从 上 面 代 码 中 可 见 ， 在 构建 Command 时 ， 传 给 Command 的 第 一 个 参数 是 org. apache. 
spark. executor. CoarseGrainedExecutorBackend ， 该 参数 表示 mainClass。 因 此 builder start 启动 的 
进程 就 是 org. apache. spark. executor. CoarseGrainedExecutorBackend 进程 ， 并 且 在 启动 中 指定 了 
进程 所 占 处 理 内 核 的 个 数 、 内 存 及 JVM 配置 信息 。 

在 CoarseGrainedExecutorBackend 进程 启动 后 ， 将 会 向 Driver 端 发 起 注册 请 求 。 之 所 以 要 
向 Driver 注册 ， 是 因为 实际 控制 Executor 计算 任务 的 还 是 Driver，Master 只 是 间接 地 为 Driver 
分 配 了 Executor， 分 配 好 了 之 后 ， 使 用 权 便 交 到 Driver 手中 。Driver 要 知道 Master 都 为 自己 
分 配 了 哪些 Executor， 这 些 Executor 都 位 于 哪些 Worker 中 ， 因 此 Executor 在 Worker 上 启动 
成 功 后 ， 主 动 去 联系 它 的 “主人 ”， 向 Driver 注册 ， 以 免 “ 主 人 ”长 时 间 等 待 Master 分 配 的 
资源 。RegisterExecutor 消息 在 CoarseGrainedExecutorBackend 的 onStart 方法 中 发 出 ， 源 代码 
如 下 所 示 。 























1. override def onStart( ) | 

2 logInfo( " Connecting to driver:" + driverUrl ) 

3 rpcEnv. asyncSetupEndpointRefByURI( driverUrl). flatMap | ref => 

4 // This is a very fast action so we can use " ThreadUtils. sameThread" 
SR driver = Some(ref ) 

0 // 疝 Driver 发 送 ask 请 求 ,等 待 Driver 的 回应 

多 ref. ask[ RegisterExecutorResponse | ( 

8 RegisterExecutor( executorld , self, hostPort , cores ,extractLogUrls ) ) 
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9 |} (ThreadUtils. sameThread ). onComplete | 

10. // This is a very fast action so we can use " ThreadUtils. sameThread" 
11. // 成 功 

六 case Success( msg) => Utils. tryLogNonFatalError | 

13. Option( self). foreach( _. send( msg) ) // msg must be RegisterExecutorResponse 
14. | 

15. // 失 败 

16. case Failure(e) => | 

17. logError( s" Cannot register with driver: $ driverUrl" ,e) 

18. System. exit( 1) 

19. | 

20. | (ThreadUtils. sameThread ) 

21. | 


上 面 代码 中 的 第 3 行使 用 rpcEnv 得 到 Driver 的 一 个 端点 引用 ， 然 后 使 用 ask 方法 向 
Driver 发 出 RegisterExecutor (executorld ,self,hostPort ,cores ,extractLogUrls) 请 求 ，Driver 端 收 
到 请 求 后 完成 Executor 的 注册 ， 并 返回 RegisteredExecutor 消息 ，CoarseGrainedExecutorBack- 
end 的 receive 方法 收 到 RegisteredExecutor 消息 后 ， 会 立 即 创建 一 个 Executor 执行 器 。 源 代码 
如 下 所 示 。 


case RegisteredExecutor( hostname) => 


1 

也 logInfo(" Successfully registered with driver" ) 
3 // 创 建 Executor 执行 器 
4 


executor = new Executor( executorld ,hostname ,env , userClassPath ,isLocal = false ) 


上 面 代 码 中 ， 匹 配 到 RegisterdExecutor 消息 ， 证 明 CoarseGraindedExecutorBackend 在 
Driver 端 已 经 注册 ， 并 打印 出 注册 成 功 的 信息 ， 然 后 后 创建 Executor。Executor 将 协助 Coar- 
seGraindedExecutorBackend 完成 计算 任务 。 

Executor 在 启动 和 执行 计算 任务 过 程 中 都 有 可 能 遇 到 错误 或 者 异常 ， 下 一 节 将 讲解 在 
Executor 中 是 如 何 进行 异常 处 理 的 。 


Executor 的 异常 处 理 ) 


Executor 在 启动 和 执行 计算 任务 过 程 中 都 有 可 能 遇 到 错误 或 者 异常 ,会 遇 到 哪些 错误 
呢 ? 看 一 下 Executor 的 run 方法 就 知道 了 ， 在 run 方法 中 通过 try - catch 语句 捕获 了 常见 的 
异常 ， 这 些 异 常 包括 FetchFailedException 、TaskKilledException 、CommitDeniedException 、 任 
何 可 Throwable 的 异常 。Executor 中 是 如 何 处 理 异常 的 呢 ?” 看 一 下 源 代码 吧 ， 下 面 是 捕获 异 
第 的 代码 。 

















ll // FetchFailedException: 抓 取 shuffle Block 时 发 生 异 党 
2 case ffe:FetchFailedException => 


3. val reason = ffe. toTaskEndReason 
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execBackend. statusUpdate(taskId ,TaskState. FAILED , ser. serialize( reason ) ) 
// TaskKilledException : 当 一 个 任务 被 显 式 地 结束 时 抛 出 该 异 浓 
case _:TaskKilledException | _:InterruptedException if task. killed => 
logInfo( s" Executor killed $ taskName (TID $ taskId)") O) 
execBackend. statusUpdate(taskId ,TaskState. KILLED , ser. serialize( TaskKilled ) ) 
//CommitDeniedException: 当 task 尝试 向 HDFS 写 出 任务 但 被 Driver 拒绝 时 抛 出 该 














球 


case CDE :CommitDeniedException => 
val reason = cDE. toTaskEndReason 
execBackend. statusUpdate(taskId ,TaskState. FAILED , ser. serialize( reason ) ) 
//Throwable: 其 他 类 型 的 异常 
case t:Throwable => 
logError(s" Exception in $ taskName (TID $ taskld)" ,t) 
val metrics: Option[ TaskMetrics | = Option( task). flatMap | task => 
task. metrics. map | m => 
m. setExecutorRunTime( System. currentTimeMillis( ) ~ taskStart ) 
m. setJvmGCTime( computeTotalGcTime( ) - startCCTime ) 
m. updateAccumulators( ) 


m 


DO DODD 一 一 一 一 re Re 
Sa cr 


| 
上 面 代码 中 ， 直 到 异常 分 别 做 以 下 处 理 。 


e FetchFailedException: 抓 取 shuffle Block 时 发 生 异 常 。 捕 获 到 这 个 异常 之 后 ， 将 会 传递 
给 DAGScheduler， 并 且 DAGScheduler 将 重新 提交 前 一 个 Stage。 捕 获 到 该 异常 后 ， 会 


调用 CoarseGrainedExecutorBackend 的 statusUpdate 方法 ， 这 个 方法 将 向 Driver 发 送 Sta- 
tusUpdate 消息 ， 消 息 中 包括 taskId 、executorId 、taskState， 以 及 捕获 的 异常 堆栈 信息 。 
Driver 匹配 到 StatusUpdate 消息 ， 调 用 TaskSchedulerImpl 的 statusUpdate 方法 ， 完 成 更 
新 任务 相关 登记 信息 并 重新 调度 资源 执行 失败 任务 。 

TaskKilledException: 当 一 个 任务 被 显 式 地 结束 时 抛 出 该 异常 ， 例 如 : 任务 失败 ， 线 程 
被 中 断 。 当 捕获 到 该 异常 时 ， 会 执行 execBackend. statusUpdate (taskId, TaskState. 
KILLED , ser. serialize ( TaskKilled ) ) ， 该 语句 调用 了 CoarseGrainedExecutorBackend 的 
statusUpdate 方法 ， 并 将 taskId 、TaskState. KILLED 及 错误 信息 传人 该 方法 ， 最 后 通过 
driverRef. send( msg ) 的 方式 将 StateUpdate (executorld ,tasked,state, data) 消息 发 送 到 
CoarseGrainedExecutorBackend 中 ， 在 CoarseGrainedExecutorBackend 的 receive 方法 中 匹 
配 到 StatusUpdate (executorld ,taskld , state ,data) 消息 ， 将 会 执行 与 FetchFailedExcep- 
tion 类 似 的 操作 ， 即 更 新 登记 信息 表 并 重新 调度 资源 运行 任务 。 
CommitDeniedException : 当 task 尝试 向 HDFS 写 出 任务 但 被 Driver 拒绝 时 抛 出 该 异常 。 
该 异常 的 处 理 与 FetchFailedException 完全 一 样 。 

e Throwable: 其 他 类 型 的 异常 ， 将 终止 Executor， 并 重新 调度 资源 。 


























呈 | 
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5 执行 器 的 通信 接口 ( ExecutorBackend) 





ExecutorBackend 是 Executor 向 集群 发 送 更 新 消息 的 一 个 可 搬 拔 的 接口 。ExecutorBackend 
拥有 不 同 的 实现 ，Standalone 模式 下 ExecutorBackend 的 默认 实现 是 CoarseGrainedExecutor- 
Backend; Local 模式 下 ExecutorBackend 的 默认 实现 是 LocalBackend; Mesos 调度 模式 下 Exec- 
utorBackend 的 默认 实现 是 MesosExecutorBackend。 本 节 主 要 探讨 Standalone 模式 下 的 Execu- 
torBackend ， 通 过 源 代码 深入 理解 ExecutorBackend 接口 设计 的 精髓 。 


El ExecutorBackend 接口 与 Executor 的 关系 | 


在 此 详细 分 析 在 Standalone 模式 下 ExecutorBackend 和 Executor 的 关系 。 在 SparkDeploy- 
SchedulerBackend 中 会 实例 化 一 个 AppClient。AppClient 中 携带 了 command 信息 ， 在 com- 
mand 信息 中 指定 了 要 启动 的 ExecutorBackend 的 实现 类 。 在 Standalone 模式 下 ， 该 Executor- 
Backend 的 实现 类 是 org. apache. spark. executor. CoarseGrainedExecutorBackend 类 。SparkDe- 
ploySchedulerBackend 中 实例 化 AppClient 的 源 代码 如 下 所 示 。 







































































I //command 中 指定 ExecutorBackend 的 实现 类 

2 val command = Command ( " org. apache. spark. executor. CoarseGrainedExecutorBackend" ， 
3 args ,SC. executorEnvs ,classPathEntries + + testingClassPath,libraryPathEntries, javaOpts) 
4. val appUIAddress = sc. ui. map(_. appUIAddress). getOrElse("") 

3 val coresPerExecutor = conf. getOption( " spark. executor. cores" ). map(_. toInt) 

6. // 使 用 Commond 等 信息 构建 application 的 描述 对 象 ApplicationDescription 

J val appDesc = new ApplicationDescription( sc. appName ,maxCores , sc. executorMemory, 
8. command ,appUIAddress ,sc. eventLogDir ,sc. eventLogCodec ,coresPerExecutor ) 

9. // 将 appDese 作为 参数 ,创建 AppClient 

10. client = new AppClient( sc. env. rpcEnv ,masters ,appDesc , this ,conf) 

11. // 调 用 start 方法 ,启动 AppClient 

2 client. start( ) 

13.  // 将 状态 设置 成 SUBMITTED 

14. launcherBackend. setState( Spark AppHandle. State. SUBMITTED ) 

15. /等 待 登记 注册 

16. waitForRegistration( ) 

17. ”// 将 状态 设置 成 RUNNING 

18. launcherBackend. setState( SparkAppHandle. State. RUNNING) 


上 面 代码 中 的 第 2 行 构建 了 一 个 Command 对 象 ， 该 对 象 的 第 一 个 参数 表示 main- 
Class， 即 进程 的 主 类 。 该 类 在 Standalone 模式 下 为 org. apache. spark. executor. CoarseG- 
rainedExecutorBackend。 分 别 得 到 sparkJavaopts 、java0pts 、command 、appUiAddress 、co- 
resPerExecutor 及 appDes 传人 AppClient 的 构造 函数 。AppClient 将 会 向 Master 发 送 Regis- 
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terApplication 注册 请 求 ，Master 受理 后 通过 launchExecutor 方法 在 Worker 结 点 启动 一 个 
ExecutorRunner 对 象 ， 该 对 象 用 于 管理 一 个 Executor 进程 。 在 ExecutorRunner 中 将 通过 
CommandUti 构建 一 个 ProcessBuilder， 调 用 ProcessBuilder 的 start 方法 将 会 以 进程 的 方式 
启动 org. apache. spark. executor. CoarseGrainedExecutorBackend。 在 CoarseGrainedExecotor- 
Backend 的 onStart 方法 中 ， 将 会 向 Driver 端 发 送 RegisterExecutor (executorId , self, host- 
Port, cores ,extractLogUrls) 消息 请 求 注册 ， 完 成 注册 后 将 立即 返回 一 个 RegisteredExecu- 
tor (executorAddress. host) 消息 ，CoarseGraiendExecutorBackend 收 到 该 消息 ， 马 上 实例 
化 出 一 个 Executor。 源 代码 如 下 所 示 。 


1. case RegisteredExecutor( hostname) => 
2: logInfo( " Successfully registered with driver" ) 


3. executor = new Executor( executorId ,hostname ,env ,userClassPath ,isLocal = false ) 


从 这 里 可 以 看 出 ，CoarseGrainedExecutorBackend 比 Executor 先 实例 化 。CoarseGrainedEx- 
ecutorBackend 负责 与 集群 通信 ， 而 Executor 则 专注 于 任务 的 处 理 ， 它 们 是 一 对 一 的 关系 ， 在 
集群 中 各 司 其 职 ， 其 关系 如 图 5-2 所 示 。 


CoarseGrainedExecutorBackend 





Executor 











CoarseGrainedExecutorBackend 





Executor 























图 $-2 CoarseGrainedExecutorBackend 和 Executor 





每 一 个 Worker 结 点 上 可 以 局 动 多 个 CoarseGrainedExecutorBackend 进程 ， 每 一 个 进程 对 
应 一 个 Executor。 


S22 ExecutorBackend 的 不 同 实现 


ExecutorBackend 是 一 个 和 集群 交互 的 接口 ， 该 接口 在 不 同 的 调度 模式 下 有 不 同 的 实现 。 
图 5-3 所 示 是 ExecutorBackend 及 其 实现 的 关系 类 图 。 
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oo- ExecutorBackend 
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LocalExecutorBackend 











cok : SparkConfig 

- scheduler : TaskSchedulerImpl 
— totalCores : int 

+ launchTask () | 


| + registered () 
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MesosExecutorBackend 








conf : SparkConfig 
scheduler : TaskSchedulerImpl 
totalCores : int 


onStart ( 
receive () 





+ onStart () 
+ receive () 

















5-3 ”ExecutorBackend 的 不 同 实现 


不 同 模式 下 ，ExecutorRunner 启动 的 进程 是 不 一 样 的 。 在 Standalone 模式 下 ， 启 动 的 是 
org. apache. spark. executor. CoarseGrainedExecutorBackend 进程 ; 在 Local 模式 下 启动 的 是 
org. apache. spark. executor. LocalExecutorBackend 进程 ， 在 Mesos 模式 下 启动 的 是 org. apache. 
spark. executor. MesosExecutorBackend 进程 。 

下 面 来 看 一 下 Standalone 模式 下 CoarseGrainedExecutorBackend 的 启动 。 在 Standalone 模 
式 下 ,会 启动 org. apache. spark. deloy. Client 类 ， 该 类 将 向 Master 发 送 RequestSubmitDriver 
( driverDescription) 消息 ，Master 中 匹配 到 RequestSubmitDriver( driverDescription ) 后 ， 将 会 调 
用 schedule( ) 方 法 。 该 调用 源 代码 如 下 所 示 。 





1. case RequestSubmitDriver( description) => | 

2 [[ 若 state 不 为 ALIVE ,直接 向 Client 返回 SubmitDriverResponse( self ,false, None,msg) 消息 
3 if (state | = RecoveryState. ALIVE ) | 

4 val msg =s" $ |Utils. BACKUP_STANDALONE_ MASTER_PREFIX| : $ state. " + 
5. " Can only accept driver submissions inALIVE state. " 

6 context. reply( SubmitDriverResponse( self ,false, None, msg ) ) 

| else | 

8 logInfo( " Driver submitted " + description. command. mainClass ) 

9 // 使 用 description 创建 Driver, 该 方法 返回 DriverDescription 

10. val driver = createDriver( description ) 

11. /持久 化 引擎 持久 化 该 Driver, 以 便 异 常 退出 错误 恢复 

12. persistenceEngine. add Driver( driver) 

13. //waitingDrivers 等 待 调度 数组 中 加 入 该 Driver 

14. waitingDrivers += driver 

lS: // 问 drivers 这 个 HashSet 中 加 入 Driver 

16. drivers. add ( driver) 

1 六 // 调 用 schdule 方法 调度 资源 





18. schedule( ) 
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19. // 问 ClientEndpoint 回复 SubmitDriverResponse 消息 

20. context. reply( SubmitDriverResponse( self ,true, Some( driver. id ) ， 

2 s" Driver successfully submitted as $ | driver. id}")) 

22. | 

2 | 

1 private def schedule( ) :Unit = | 

2. // 若 Master 的 状态 不 为 ALIVE , 则 直接 返回 

3 if (state ! = RecoveryState. ALIVE) | return | 

4 // Drivers take strict precedence over executors 

5 // 随 机 打 乱 Worker 这 个 HashSet 中 Worker 的 次 序 , 用 于 Driver 在 集群 中 随机 加 载 ,起 到 
平衡 加 载 的 作用 ,从 这 里 也 可 以 看 出 ,Driver 是 在 集群 中 随机 的 Worker 上 启动 的 

6. val shuffled Workers = Random. shuffle( workers) // Randomization helps balance drivers 
7 // 遍 历 状态 为 ALIVE 的 Worker 

8. for (worker <— shuffledWorkers if worker state == WorkerState. ALIVE ) | 

由 // 从 waitingDrivers 中 取出 Driver ,并 进行 匹配 

10. for (driver <— waitingDrivers) | 

11. ”// 如 果 Driver 和 Worker 匹配 ,内 存 和 运行 核 都 将 得 到 满足 

[2 if (worker. memoryFree >= driver. desc. mem && worker. coresFree >= driver desc. cores) | 
13. /在 该 Worker 上 启动 加 载 Driver 

14. launchDriver( worker , driver ) 

Ss // 加 载 Driver 后 ,从 waitingDrivers 中 移 除 该 Driver 

16. waitingDrivers —= driver 

[5 } 

18. | 

19. } 

20. startExecutorsOnWorkers( )// 为 application 在 worker 上 启动 Executor 

2 } 


上 面 代 码 中 ，RecoveryState 若 不 为 ALIVE， 则 直接 返回 ， 和 否则 使 用 Random. shuffle 将 
Worker 集合 打 乱 生成 新 的 集合 shuffledWorkers， 这 样 会 尽量 考虑 到 选择 Driver 的 负载 均衡 。 
在 for 语句 中 遍历 shuffledWorkers， 首 先 ， 若 Worker 的 WorkerStage 为 ALIVE， 则 遍历 wait- 
ingDrivers 队列 ， 判 断 Worker 剩余 内 存 和 剩余 物理 核 是 否 满 足 Driver 需求 ， 如 满足 则 调用 
launchDriver (worker，driver) 方法 在 选中 的 Worker 上 启动 Driver 进程 。 

Driver 在 Worker 结 点 上 启动 起 来 之 后 ， 会 实例 化 SparkContext， 在 SparkContext 中 将 实 
例 化 出 DAGScheduler 和 SparkDeloySchedulerBackend。 在 SparkDeploySchedulerBackend 中 将 会 
new 一 个 AppClient，AppClient 中 有 一 个 ClientEndpoint， 在 其 onStart 方法 中 将 向 Master 发 送 
RegisterApplication 请 求 注册 application ， 注 册 好 application 之 后 Master 又 会 调用 schedule 方 
法 。 在 满足 条 件 的 Worker 上 为 application 启动 Executor， 首 先 会 启动 ExecutorRunner， 在 Ex- 
ecutorRunner 中 启动 CoarseGrainedExecutorBackend ， 启 动 后 将 会 实例 化 出 Executor。 为 什么 在 
Standalone 模式 下 会 启动 CoarseGrainedExecutorBackend 呢 ? 是 在 什么 地 方 设 置 要 启动 Coar- 
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seGrainedExecutorBackend 进程 的 呢 ? 其 实在 实例 化 AppClient 时 ， 就 已 经 传人 了 ， 源 代码 如 
下 所 示 。 


















































1. //command 中 指定 ExecutorBackend 的 实现 类 

2 val command = Command( " org. apache. spark. executor. CoarseCrainedExecutorBackend'" ， 
于 args, sc. executorEnvs ,classPathEntries + + testingClassPath ,libraryPathFEntries ,javaOpts ) 
4. val appUIAddress = sc. ui. map( _. appUIAddress). getOrElse("") 

Sh val coresPerExecutor = conf getOption( " spark. executor. cores" ). map(_. toInt) 

6. // 使 用 Commond 等 信息 构建 application 的 描述 对 象 ApplicationDescription 

9 val appDesc = new ApplicationDescription( sc. appName ,maxCores ,sc. executorMemory ， 
8. command ,appUIAddress ,sc. eventLogDir,sc. eventLogCodec ,coresPerExecutor ) 

9. // 将 appDese 作为 参数 ,创建 AppClient 

10. client =new AppClient( sc. env. rpcEnv ,masters ,appDesc ,this ,conf) 

11. /调用 start 方 法 ,启动 AppClient 

2 client. start( ) 

13. /将 状态 设置 成 为 SUBMITTED 

14. launcherBackend. setState( SparkAppHandle. State. SUBMITTED ) 

15. /等 待 登记 注册 

16. waitForRegistration( ) 

17. /将 状态 设置 成 为 RUNNING 

18. launcherBackend. setState( Spark AppHandle. State. RUNNING) 


上 面 代码 中 的 第 2 行 设置 了 Command 对 象 ，Command 对 象 的 第 一 个 参数 是 启动 进程 的 
mainClass。 因 此 在 ExecutorRunner 中 启动 进程 时 ， 启动 的 即 是 org. apache. spark. executor. 


CoarseGrainedExecutorBackend。 








ExecutorBackend 中 的 通信 ) 





在 ExecutorBackend 中 有 statusUpdate (taskId: Long, state: TaskState, data: ByteBuffer) 方 
法 ， 通 过 这 个 方法 向 集群 发 送 Task 执行 的 各 种 信息 。 如 果 任 务 执行 失败 ， 返 回 失败 的 信息 ; 
如 果 执 行 成 功 ， 返 回 任务 执行 的 结果 。 在 本 节 中 ， 将 重点 讲解 在 Standalone 模式 下，Coar- 
seGrainedExecutorBackend 中 的 通信 。 CoarseGrainedExecutorBackend 在 整个 集群 中 的 通信 
如 图 5-4 所 示 。 

在 图 5-4 中 ，Executor 与 CoarseGrainedExecutorBackend 协作 ,任务 计算 的 结果 通过 
CoarseGrainedExecutorBackend 的 statusUpdate 方法 将 taskId、TaskState 及 结果 数据 发 送 给 
Driver。Driver 收 到 StatusUpdate (executorld ,tasked ,state ,data) 消息 ， 通 过 判断 state 的 不 同 
的 状态 来 进行 不 同 的 处 理 。 比 如 ， 当 state 的 状态 为 TaskState. LOST 时 ，Driver 端 将 会 移 除 
Executor; 当 state 状态 为 TaskState. FINISHED 时 ，Driver 端 将 会 调用 enqueueSuccessfulTask 
进行 处 理 。 

首先 看 一 下 CoarseGrainedExecutorBackend 与 Driver 之 间 的 通信 。 当 在 Worker 结 点 中 局 
动 ExecutorRunner 时 ，ExecutorRunner 中 会 启动 CoarseGrainedExecutorBackend 进程 ， 在 Coar- 
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Master 结 点 


Worker 结 点 Driver 结 点 Worker 结 点 


CoarseGrainedExecutorBackend CoarseGrainedExecutorBackend 


Executor Executor 


图 5-4 ”CoarseGrainedExecutorBackend 在 整个 集群 中 的 通信 























seGrainedExecutorBackend 的 onStart 方法 中 ， 向 Driver 发 出 RegisterExecutor 注册 请 求 。 源 代 
码 如 下 所 示 。 


1. override def onStart( ) | 

logInfo( " Connecting to driver:" + driverUrl ) 

3 rpcEnv. asyncSetupEndpointRefByURI( driverUrl). flatMap | ref => 

4 // This is a very fast action so we can use " ThreadUtils. sameThread" 
3 driver = Some(ref ) 

6 // 向 Driver 发 送 ask 请 求 ,等 待 Driver 的 回应 

ref. ask[ RegisterExecutorResponse | ( 

8 RegisterExecutor( executorld , self, hostPort, cores ,extractLogUrls ) ) 
9. | (ThreadUtils. sameThread). onComplete | 

10. // 成 功 

11. case Success( msg) => Utils. tryLogNonFatalError | 

[2 Option( self). foreach( _. send( msg) ) // msg must be RegisterExecutorResponse 
13. } 

14. // 失 败 

15. case Failure(e) => | 

16. logError( s" Cannot register with driver: $ driverUrl" ,e) 

a System. exit(1) 

18. | 

19. | (ThreadUtils. sameThread ) 

20.， | 








内 核 机 制 解析 及 性 能 调 优 





上 面 代 码 中 ，Some(ref) 得 到 Driver 的 引用 ， 通 过 ask 方法 返回 Future[ RegisterExecutor- 
Response] ， 然 后 在 Future 对 象 上 调用 onComplete 方法 进行 额外 的 处 理 。Driver 端 收 到 注册 
请 求 ， 将 会 注册 Executor 的 请 求 ， 并 向 ListenerBus 中 发 送 SparkListenerExecutorAdded 事件 。 
处 理 源 代 码 如 下 所 示 。 











有 case RegisterExecutor( executorId ,executorRef, hostPort ,cores ,logUrls) => 
外 // 检 查 executorDataMap 中 是 否 包 含 该 executorld, 如 果 包 含 ,返回 RegisterExecutorFailed 























3. i (executorDataMap. contains( executorId) ) | 

4. context. reply( RegisterExecutorFailed( " Duplicate executor ID:" +executorld)) 

SE | else | 

6. [[ 若 executorRef. address 地 址 不 为 null, 取 出 executorRef 的 地 址 作为 executo- 
rAddress, 否则 使 用 sender 的 Address 作为 executorAddress 

a val executorAddress = if (executorRef. address ! =null) | 


8. executorRef. address 

















9. | else | 

10. context. senderAddress 

11. } 

12. logInfo( s" Registered executor $ executorRef ( $ executorAddress) with ID $ 

executorld" ) 

13. // 在 addressToExecutorId 这 个 哈 希 表 中 加 入 executorAddress 和 executorld 的 对 应 
关系 

14. addressToExecutorId( executorAddress ) = executorld 

LS //totalCore 增加 core 的 个 数 

16. totalCoreCount. add AndGet( cores ) 

17. //totalRegisteredExecutors 加 1 

18. totalRegisteredExecutors. addAndGet( 1) 

19. // 创 建 ExecutorData 对 象 

20. val data = new ExecutorData( executorRef,executorRef. address ,executorAddress. host, 

Sl cores ,cores , logUrls ) 

2 // 同 步 代码 块 

2 CoarseGrainedSchedulerBackend. this. synchronized | 

24. // 在 executorDataMap 中 加 入 executorld 和 ExecutorData 的 对 应 关系 

25: executorDataMap. put( executorld ,data ) 

26. // 如 果 挂 起 的 Executor 的 数量 大 于 0 

多 if (numPendingExecutors >0) | 

28. // 挂 起 Executor 的 数量 减 1 

2 numPendingExecutors —= 1 

30. logDebug( s" Decremented number of pending executors ( $ numPendingExecutors left)") 

31. } 

3 } 


33. // 问 CoarseGrainedExecutorBackend 回复 RegisteredExecutor 消息 
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34. context. reply( RegisteredExecutor( executorAddress. host ) ) 

35. // 问 事件 总 线 中 发 送 SparkListenerExecutorAdded 消息 

36. listenerBus. post( 

3 SparkListenerExecutorAdded( System. currentTimeMillis( ) ,executorld , data ) ) O) 
38. // 调 用 makeOffers ,给 Executor 发 送 执行 任务 

39. makeOffers( ) 

40. | 

















如 上 面 代码 所 示 ， 如 果 executorDataMap 中 已 经 存在 该 Executor 的 id， 返回 RegisterExec- 
utorFailed; 如 果 不 存在 该 Executor 的 id， 则 在 executorDataMap 中 加 入 该 Executor 的 id， 并 返 
回 RegisteredExecutor 消息 且 癌 listenerBus 中 添加 SparkListenerExecutorAdded 事件 。CoarseG- 
rainedExecutorBackend 收 到 RegisteredExecutor 消息 后 ， 将 会 新 建 一 个 Executor 执行 需 ， 并 为 
此 Executor 充当 信使 与 Driver 通信 。CoarseGrainedExecutorBackend 收 到 RegisteredExecutor 消 
息 的 源 代码 如 下 所 示 。 








1l. case RegisteredExecutor( hostname) => 
2 logInfo( " Successfully registered with driver" ) 
// 收 到 RegisteredExecutor 消息 ,立即 创建 Executor 


3. executor = new Executor( executorId ,hostname ,env, userClassPath ,isLocal = false) 


从 上 面 代码 中 可 以 看 到 ，CoarseGrainedExecutorBackend 收 到 RegisteredExecutor (host- 
name) 消息 后 ， 将 会 新 建 一 个 Executor。 由 此 可 见 ，Executor 较 CoarseGrainedExecutorBack- 
end 后 实例 化 ， 这 与 Executor 和 CoarseGrainedExecutorBackend 的 不 同 职 责 有 关 ，Executor 主 
要 负责 计算 ， 而 CoarseGrainedExecutorBackend 主要 负责 通信 ， 通 信 环 境 准备 好 了 ， 架 起 了 同 
CoarseGrainedSchedulerBackend 通信 的 桥 粱 ， 就 可 以 接收 CoarseGrainedSchedulerBackend 中 调 
用 launchTask 方法 发 送 的 LaunchTask 消息 了 ， 因 此 通信 在 前 ， 计 算 在 后 。 

Executor 中 的 计算 结果 是 通过 CoarseGrainedExecutorBackend 的 statusUpdate 方法 返回 给 
CoarseGrainedExecutorBackend 的 ，statusUpdate 方法 的 代码 如 下 所 示 。 












































override def statusUpdate(taskId:Long,state:TaskState ,data:ByteBuffer) | 
// 构 建 StatusUpdate 对 象 





val msg = StatusUpdate ( executorld ,taskId ,state , data ) 
driver match | 


1 
2 
3 
4 
$ // 问 Driver 发 送 StatusUpdate 消息 
6 
% 
8 
9 





case Some( driverRef) => driverRef send( msg) 


case None => logWarning(s" Drop $ msg because has not yet connected to driver" ) 


| 


上 面 源 代码 中 ， 通 过 参数 taskId 、state 和 data 构建 一 个 StatusUpdate 对 象 ， 该 对 象 将 被 
当做 消息 发 送 到 Driver 端 ，Driver 根据 返回 结果 的 需要 ， 将 会 向 CoarseGrainedExecutorBack- 
end 发 送 新 的 指令 消息 ， 如 LaunchTask 、KillTask 、StopExecutors 和 Shutdown 等 。 












内 核 机 制 解析 及 性 能 调 优 


执行 器 (Executor) 中 任务 的 执行 
Executor 中 任务 的 加 载 





Executor 是 基于 线程 池 的 任务 执行 器 ， 通 过 launchTask( ) 方 法 加 载 任务 ,将 任务 以 Task- 
Runner 的 形式 放 入 线程 池 中 运行 。 

DAGScheduler 划分 好 Stage 并 通过 submitMissingTasks 方法 分 配 好 任务 ， 并 把 任务 交 由 
TaskSchedulerImpl 的 submitTasks 方法 ， 将 任务 加 入 调度 池 ， 之 后 调用 CoarseGrainedSchedul- 
erBackend 的 riviveOffers 方法 为 Task 分 配 资源 指定 Executor。 任 务 资源 都 分 配 好 之 后 ，Coar- 
seGrainedSchedulerBackend 将 向 CoarseGranedExecutorBackend 发 送 LaunchTask 消息 ， 将 具体 
的 任务 发 送 到 Executor 上 进行 计算 。 

CoarseGranedExecutorBackend 匹配 到 LaunchTask (data) 消息 之 后 ， 将 会 调用 Executor 
的 launchTask 方法 。launchTask 方法 中 将 会 构建 TaskRunner 对 象 并 放 和 线程 池 中 执行 。 

具体 的 调用 流程 如 图 5-5 所 示 。 


riviveOffers 


makeOffer 


launchTasks 
发 送 LaunchTask 消 息 
调用 LaunchTask 方 法 








到 








5-5 ”Executor 中 Task 的 加 载 时 序 图 
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任务 加 载 好 了 之 后 ， 在 Executor 中 将 会 把 构建 好 的 TaskRunner 放 入 线程 池 运 行 ， 至 此 
任务 完成 加 载 ， 开 始 运 行 。 





3 Executor 中 的 任务 线程 池 S 


Executor 是 构建 在 线程 池 之 上 的 任务 执行 器 。 在 Executor 中 使 用 线程 池 可 以 减少 在 
创建 和 销毁 线程 上 所 花 的 时 间 和 系统 资源 开销 。 如 果 不 使 用 线程 池 ， 可 能 造成 系统 创 
建 大 量 的 线程 而 导致 消耗 完 系统 内 存 ， 以 及 出 现 “ 过 度 切 换 ”。 

在 Executor 中 使 用 线程 池 基 于 以 下 两 点 原因 ， 首 先 在 Executor 端 执 行 的 任务 处 理 时 间 都 
比较 短 ， 需 要 频繁 地 创建 和 销毁 线程 ， 这 样 就 带 来 了 巨大 的 创建 和 销毁 线程 的 开销 ， 造 成 额 
外 的 系统 资源 开销 ; 其 次 Executor 中 处 理 的 任务 数量 巨大 ， 如 果 每 一 个 任务 都 创建 一 个 线 
程 ， 将 导致 消耗 完 系 统 内 存 ， 出 现 “ 过 度 切换 ”。 

首先 看 一 下 Executor 中 的 线程 池 。Executor 中 使 用 的 是 CachedThreadPool， 使 用 这 种 类 
型 线程 池 的 好 处 是 ， 任 务 比 较 多 时 可 以 自动 新 增 处 理 线程 ， 而 任务 比较 闲 时 自动 回收 空闲 线 
程 。Executor 中 的 线程 池 的 源 代 码 定 义 如 下 所 示 。 








private val threadPool = ThreadUtils. newDaemonCachedThreadPool( "Executor task launch worker" ) 


CoarseGrainedExecutorBackend 调用 Executor 的 launchTask 方法 ， 在 方法 中 将 会 新 建 Task- 
Runner， 然 后 放 入 线程 池 进 行 处 理 。 源 代码 如 下 。 


1. val tr=new TaskRunner( context ,taskId = taskld ,attemptNumber = attemptNumber, taskName, 
人 2 serializedTask ) 

3. runningTasks. put( tasklId ,tr) 
4 


. threadPool. execute( tr) 


从 上 面 的 源 代码 中 可 以 看 到 ， 新 建 的 TaskRunner 对 象 首先 放 入 runningTasks 这 样 一 个 
ConcurrentHashMap 里 面 ， 然 后 使 用 线程 池 的 execute 方法 运行 TaskRunner，execute 方法 将 会 
调用 TaskRunner 的 run 方法 ， 在 TaskRunner 的 run 方法 中 执行 计算 任务 。 


任务 执行 失败 处 理 ) 


TaskRunner 在 计算 的 过 程 中 可 能 发 生 各 种 异常 甚至 错误 ,例如 抓 取 Shuffle 结果 失败 、 
任务 被 杀 死 、 没 权限 向 HDFS 写 入 数据 等 ， 当 TaskRunner 的 run 方法 运行 时 ， 可 以 通过 try 
catch 语句 捕获 这 些 异 常 ， 并 通过 调用 CoarseGrainedExecutorBackend 的 statusUpdate 方法 向 
CoarseGrainedSchedulerBackend 汇报 。 

下 面 是 CoarseGrainedExecutorBackend 的 statusUpate 方法 源 代码 。 








1. override def statusUpdate(taskId :Long ,state:TaskState ,data:ByteBuffer) | 
2 val msg = StatusUpdate( executorld ,taskId ,state , data)// 构 建 StatusUpdate 消息 对 象 


9 driver match | 








© 
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case Some( driverRef) => driverRef send(msg)Z/ 向 driver 发 送 StatusUpdate 消息 


case None =>logWarning(s" Drop $ msg because has not yet connected to driver" ) 


ES 


| 





在 statusUpdate 方法 中 ， 通 过 方法 的 参数 taskId 、state 和 data 构建 一 个 StatusUpdate 对 
象 ， 并 通过 driverRef 的 send 方法 将 该 对 象 发 送 回 CoarseGrainedSheduleBackend。 CoarseG- 
rainedScheduleBackend 匹配 到 StatusUpdate 时 ， 将 根据 StatusUpdate 对 象 中 的 state 值 来 对 该 
Task 的 执行 情况 做 出 判断 ， 并 执行 不 同 的 处 理 逻 辑 。 

TaskState 是 一 个 枚 举 变量 ， 其 中 包括 LAUNCHING、RUNNING 、FINISHED 、FAILED、 
KILLED 和 LOST 这 些 枚 举 值 。Executor 根据 任务 执行 的 不 同 状态 ， 通 过 statusUpdate 方法 返 
回 特定 的 TaskState 值 ， 该 值 通过 ExecutorBackend 返回 给 SchedulerBackend， 在 Scheduler- 
Backend 中 根据 TaskState 中 的 值 进行 处 理 。 

先 来 看 一 下 TaskState. FAILED 这 种 情况 ， 在 Executor 的 run 方法 中 ， 如 果 发 生 Fetch- 
FailedExeception 、CommitDeniedExeception 或 者 其 他 Throwable 的 子 类 的 异常 ， 都 将 会 返回 
TaskState. FAILED 状态 ,该 状态 通过 CoaseGainedExecutorBackend 返回 。 在 CoaseGaiend- 
SchedulerBackend 中 ， 匹 配 到 StatusUpdate 消息 后 将 进行 相应 的 人 处理， 匹配 代码 如 下 。 




















1. case StatusUpdate( executorld ,taskld ,state ,data) => 

2 scheduler. statusUpdate(taskId ,state , data. value )// 调 用 TaskSchedulerImpl 更 新 状态 

3. 这 (TaskState. isFinished( state) ) 1// 阁 状态 为 FINISH, 则 从 executorDataMap 中 取出 ex- 
ecutorld 对 应 的 ExecutorInfo 





4 executorDataMap. get( executorId ) match | 

3 case Some( executorInfo) => 

6. executorInfo. freeCores += scheduler. CPUS_PER_TASK 
有 makeOffers( executorId)//makeOffers 方法 重新 分 配 资源 
8 
9 


case None => 





//lgnoring the update since we dou t know about the executor. 


10. logWarning( s" Ignored task status update( $ taskld state $ state)" + 
11. s" from unknown executor with ID $ executorld" ) 

| } 

| 大计 


上 面 代码 中 ， 首 先 调用 TaskSchedulerImpl 的 statusUpdate 方法 ， 该 方法 的 调用 用 于 更 新 
taskId 对 应 任务 的 状态 。 完 成 更 新 后 ， 判 断 state 状态 是 否 为 finished， 若 状态 为 finished， 则 
从 executorDataMap 这 个 哈 硕 表 中 取出 executorld 对 应 的 ExecutorData 对 象 ， 修 改 该 对 象 中 的 
freeCores。 因 为 状态 已 经 为 finished 状态 ， 因 此 ExecutorData 中 的 freeCores 会 增加 CPUS_PER 
_TASK 个 ，CPU _PER _TASK 为 每 一 个 任务 占用 的 CPU 核 的 个 数 ， 该 个 数 可 以 通过 
spark. task. cpus 配置 项 进行 配置 。 

更 新 完成 ExecutorData 上 的 可 用 CPU 后 ， 这 些 闲置 的 CPU 通过 makeOffers 方法 再 次 分 
配给 其 他 任务 使 用 。 先 来 看 一 下 makeOffers 方法 的 源 代码 ， 如 下 所 示 。 
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1. // Make fake resource offers on just one executor 

多 private def makeOffers( executorId :String ) | 

3. // 过 滤 存 活 的 Executor 

4 if( executorIsAlive( executorId ) ) | O) 
5 // 从 executorDataMap 这 个 哈 希 表 中 取出 executorld 对 应 的 ExecutorData 对 象 , Execu- 


torData 表示 Executor 上 的 一 组 资源 
val executorData = executorDataMap( executorId ) 


6. 
ge // 使 用 executorData 创建 WorkerOffer 对 象 ,该 对 象 代表 Executor 上 可 用 的 资源 
8 
9 























val workOffers = Seq( 


newWorkerOffer( executorld ,executorData. executorHost, executorData. freeCores ) ) 








10. // 调 用 TaskSchedulerImpl 上 的 resourceOffers 方法 ,为 任务 分 配 运 行 资源 ,该 方法 
返回 获得 运行 资源 的 任务 集合 ,之 后 运行 launchTasks 方法 ,将 这 些 任务 发 送 到 Executor 上 
运行 

11. launchTasks( scheduler. resourceOffers( workOffers) ) 

2 | 

ls | 








每 一 个 Executor 上 的 资源 发 生变 动 时 ， 都 将 调用 makeOffers 方法 ， 该 方法 的 作用 是 为 等 
待 执行 的 任务 分 配 资源 ， 并 通过 launchTasks 方法 将 这 些 任务 发 送 到 这 些 Executor 上 运行 。 
这 些 任务 将 被 包装 成 TaskRunner 对 象 ， 运 行 于 Executor 上 的 线程 池 中 。 





剖析 TaskRunner 

TaskRunner 位 于 Executor 中 ， 继 承 自 Runnable 接口 ， 代 表 一 个 可 执行 的 任务 ，Driver 端 
下 发 的 任务 最 终 都 要 在 Executor 中 封装 成 TaskRunner， 在 TaskRunner 的 run 方法 中 ， 将 会 进 
行 任务 的 解析 并 调用 Task 接口 的 run 方法 进行 计算 计算 。TaskRunner 的 定义 代码 如 下 。 





class Task Runner( 
execBackend :ExecutorBackend,// 通 过 execBackend 和 SchedulerBakend 通信 
val taskld :Long, 
































val attemptNumber: Int, 
taskName:String， 
serializedTask : ByteBuffer ) 


extends Runnable | 


a Je A er ee 


TaskRunner 的 构造 图 数 中 有 execBackend 、taskId 、attemptNumber 、taskName 和 serial- 
izedTask 共 5 个 参数 。 其 中 execBackend 作为 和 CoarseGrainedSchedulerBackend 通信 的 使 者 传 
入 到 TaskRunner 中 ， 在 任务 计算 状态 发 生变 化 时 ， 调 用 execBackend 的 statusUpdate 方法 向 
CoarseGrainedSchedulerBackend 报告 。 传 入 taskld 是 为 了 使 用 TaskMemoryManager 管理 该 
Task。attemptNumber 代表 任务 尝试 执行 的 次 数 ，serializedTask 是 序列 化 的 任务 ， 序 列 化 的 任 
务 通过 序列 化 工具 反 序 列 化 得 到 任务 对 象 。 

那么 ， 在 TaskRunner 中 是 如 何 运行 任务 的 呢 ? 大 家 知道 ， 在 线程 池 中 启动 Runnable 任 
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务 会 自动 调用 Runnable 的 run 方法 ，TaskRunner 作为 一 个 Runnable 接口 的 实现 类 ， 启 动 时 
会 自动 调用 其 run 方法 。run 方法 中 主要 完成 以 下 任务 。 

e 调用 ExecutorBackend 的 statusUpdate 方法 向 SchedulerBackend 发 送 任务 状态 更 新 消息 。 

e 反 序 列 化 出 Task 和 相关 依赖 Jar 包 。 

e 调用 Task 上 的 run 方法 运行 任务 。 

e 返回 Task 运行 结 

Task 是 一 个 接口 ，ResultTask 和 ShffleMapTask 是 它 的 两 种 实现 。Task 接口 中 提供 了 run 
方法 ， 用 于 运行 任务 。 在 TaskRunner 的 run 方法 中 ， 会 通过 反 序 列 化 器 反 序 列 化 出 Task 并 
调用 Task 上 的 run 方法 运行 任务 ， 这 里 怎么 知道 是 ResultTask 还 是 ShffleMapTask 呢 ? 其 实 
不 管 是 ResultTask 还 是 ShffleMapTask 都 一 视 同 仁 ， 因 为 ResultTask 和 ShffleMapTask 都 实现 了 
Task 接口 ， 都 有 run 方法 。 这 正 是 面向 接口 编程 带 来 的 最 大 的 好 人 处， 即 灵活 且 最 大 限度 地 复 
用 代码 。 

Task 将 运行 结果 分 为 3 种 情况 来 处 理 ， 第 一 种 情况 是 resultSize 大 于 maxResultSize， 这 
种 情况 下 构建 IndirectTaskResult 对 象 ， 并 返回 该 IndirectTaskResult 对 象 ，IndirectTaskResult 
对 象 中 包含 结果 所 在 的 BlockId， 在 SchedulerBackend 中 可 以 通过 BlockManager 获得 该 Block- 
Id 对 应 的 结果 数据 ， 这 里 的 maxResultSize 默认 为 1GB; 第 二 种 情况 是 resultSize 大 于 Akka 帧 
的 大 小 , 这 种 情况 下 也 是 构建 mdirectTaskResult 对 象 ， 并 返回 该 IndirectTaskResult 对 象 ， 
Akka 帧 的 大 小 为 128 MB; 第 三 种 情况 是 直接 返回 DirectTaskResult， 这 是 在 resultSize 小 于 
Akka 帧 大 小 的 情况 下 采取 的 默认 返回 方式 。 














EE 





本 章 主 要 讲解 了 Executor 及 ExecutorBackend 接口 。 在 本 章 的 5.1 小 节 中 ,通过 一 个 时 
序 图 从 整体 上 把 握 Executor 的 启动 过 程 ， 从 源 代 人 码 的 角 度 讲 解 了 Executor 创建 的 整个 过 程 
并 分 别 讲解 了 Executor 中 的 资源 分 配 及 Executor 的 启动 过 程 ， 还 讲解 了 Executor 运行 过 程 中 
的 异常 处 理 。 

Executor 只 是 一 个 任务 的 执行 句 ， 任 务 被 下 发 到 Executor 中 ， 首 先 包装 成 TaskRunner 对 
象 ， 然 后 放 和 人 到 Executor 中 的 线程 池 中 运行 。 对 于 Executor 与 Driver 端的 通信 ， 就 要 借助 于 
ExecutorBackend 接口 了 。 本 章 5. 2 小 节 中 讲解 了 ExecutorBackend 的 通信 接口 ， 讲 解 了 Exec- 
utorBackend 与 Executor 的 关系 〈 其 实 它 们 是 相互 扶持 的 “两 兄弟 ” ， 一 个 负 者 通信 ， 另 一 个 
负 者 任务 的 执行 ) 。 在 这 一 节 中 ， 还 介绍 了 ExecutorBackend 接口 的 不 同 实 现 ， 以 及 Executor- 
Backend 与 SchedulerBackend 通信 的 细节 。 

5.3 小 节 则 着 重 讲解 了 Executor 中 的 任务 执行 的 细节 ， 这 些 细节 包括 任务 的 加 载 ， 任 务 
线程 池 ， 任 务 执行 失败 处 理 ， 以 及 任务 的 载体 TaskRunner。 
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第 6 瘟 Spark 的 存储 模块 (Storage) 


Spark Storage 模块 为 用 户 提供 了 高 层次 的 抽象 ， 将 接口 和 实现 进行 了 有 效 的 隔离 ， 使 用 户 无 
须 关 心底 层 的 实现 ， 而 将 主要 精力 放 在 业务 的 实现 上 。 第 5 章 讲解 了 执行 器 〈Executor) ， 可 知 任 
务 以 TaskRunner 的 形式 运行 于 线程 池 中 ， 那 么 任务 运行 的 结果 数据 存放 在 哪里 ， 如 何 读 取 呢 ?这 
是 由 Storage 模块 来 管理 和 实现 的 ， 在 本 章 中 ， 将 会 结合 源 代码 详细 分 析 Spark 的 Storage 模块 。 

本 章 将 讲解 Storage 模块 的 基本 定义 和 接口 。 在 此 基础 上 ， 详细 剖析 Storage 的 整体 架 
构 。 最 后 讲解 OFF_HEAP 的 实现 Tachyon， 介 绍 Tachyon 在 Spark 中 的 运用 及 API 的 使 用 。 














Storage 概述 











”Storage 的 概念 


在 Spark 中 存储 模块 被 抽象 成 Storage， 顾 名 思 义 ，Storage 是 存储 的 意思 ， 代 表 着 Spark 
中 的 数据 存储 系统 ， 负 责 管理 和 实现 数据 块 (Block) 的 存放 。 其 中 存 取 数据 的 最 小 单元 是 
Block， 数 据 由 不 同 的 Block 组 成 ， 所 有 操作 都 是 以 Block 为 单位 进行 的 。 本 质 上 讲 RDD 中 
的 Partition 和 Storage 中 的 Block 是 等 价 的 ， 只 是 所 处 的 模块 不 同 看 待 的 角度 不 一 样 而 已 。 
Storage 抽象 模块 的 实现 分 为 两 个 层次 ， 如 图 6-1 所 示 。 
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内 核 机 制 解析 及 性 能 调 优 


1) 通信 和 层 : 通信 层 是 典型 的 Master - Slave 结构 ，Master 和 Slave 之 间 传 输 控 制 和 状态 
信息 。 通 信 层 主要 由 BlockManager、BlockManagerMaster、BlockManagerMasterEndpoint、 
BlockManagerSlaveEndpoint 等 类 实现 。 

2) 存储 层 : 负 者 把 数据 存储 到 内 存 、 磁 盘 或 者 堆 外 内 存 中 ， 有 时 还 需要 为 数据 在 远程 
结 点 上 生成 副本 ， 这 些 都 由 存储 层 提供 的 接口 实现 。 具 体 的 存储 层 的 实现 类 有 抽象 类 Block- 
Store ， 实 现 类 DiskStore 、MemoryStore 、ExternalBlockStore 等 。 











其 他 模块 知 要 和 Storage 模块 进行 交互 ， 需 要 通过 调用 统一 的 操作 类 BlockManager 来 完 
成 。 如 果 把 整个 存储 模块 看 成 一 个 黑 盒 ，BlockManager 就 是 黑 盒 上 留 出 的 一 个 供 外 部 调用 的 
接口 。 黑 盒 中 用 到 了 不 少 的 设计 模式 ， 下 一 小 节 将 谈 谈 Storage 抽象 实现 中 涉及 的 设计 模式 。 


对 Storage 的 设计 模式 9 


Storage 模块 中 ， 对 于 存储 层 进行 了 抽象 ， 使 用 接口 将 抽象 和 实现 进行 了 完美 的 分 离 。 
对 于 块 的 存储 ， 抽 象 出 BlockStore 类 ， 在 BlockStore 类 中 提供 抽象 和 钩子 方法 ， 实 现 不 同 存 
储 时 ， 就 可 以 灵活 的 根据 现实 情况 进行 实现 。BlockStore 有 三 个 不 同 的 实现 ,分别 是 Disk- 
Store 、MemoryStore 、ExternalBlockStore。 在 BlockManager 中 ， 存 储 块 数据 会 根据 StorageLevel 
的 设置 ， 选 择 BlockStore 的 不 同 实现 ， 而 StorageLevel 则 提供 给 用 户 ， 使 用 户 可 以 根据 机 器 
性 能 、 集 群 配置 、 使 用 场景 等 灵活 的 选择 block 的 存储 级 别 。 

正 是 因为 BlockStore 的 抽象 ， 使 得 BlockManager 的 实现 只 需要 关注 BlockStore 接口 ， 而 
不 必 关 心 繁琐 的 实现 细节 ， 这 是 面向 接口 编程 的 典型 应 用 。 并 且 Spark 为 用 户 提供 了 详尽 的 
StorageLevel, 用 户 无 需 自 己 定义 ， 只 需要 根据 实际 情况 灵活 选择 即 可 。 

实际 上 StorageLevel 是 Spark 为 用 户 提 供 的 一 个 存储 功能 选择 开关 ， 而 实现 的 细节 完全 
由 Spark Storage 模块 隐藏 。 而 且 Storage 模块 对 外 提供 了 一 个 交互 的 接口 BlockManager， 对 于 
不 同 的 存储 如 Disk 、Memory 、External 等 抽象 出 了 BlockStore， 这 使 得 BlockManager 可 以 以 
面向 接口 编程 的 方式 来 使 用 不 同 的 Store ， 而 无 需 关 心 具 体 Store 的 实现 细节 。 通 过 面向 接口 
编程 ， 保 证 了 模块 代码 的 可 复 用 性 、 灵 活性 、 可 扩展 性 以 及 程序 的 健壮 性 。 

在 Storage 通信 层 里 面 ，Slave 结 点 上 的 Executor 中 的 BlockManager 通过 BlockManagerS- 
laveEndPoint 和 Master 结 点 的 BlockManagerMasterEndpoint 进行 通信 。RPC 远程 过 程 调用 在 
Spark 中 担任 通信 功能 ， 大 大 简化 了 Spark 架构 复杂 度 。 下 一 小 节 将 详细 讲解 Storage 模块 的 
整体 架构 。 















































6.28 Storage 模块 整体 架构 





本 小 节 主 要 面向 源 代码 讲解 Storage 模块 通信 层 及 存储 层 的 架构 。6.2.1 小 节 讲 解 
Storage 模块 的 通信 层 ，6. 2. 2 小 节 讲 解 Storage 模块 的 存储 层 。 通 过 这 两 个 小 节 的 讲解 ， 
站 在 源 代码 的 角度 ， 详 细 剖 析 Storage 整体 的 架构 ， 使 读者 对 整个 存储 模块 有 个 详细 的 
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Br 通信 层 


在 Storage 模块 中 ， 使 用 RPC 框架 进行 通信 。Storage 模块 对 外 提供 了 一 个 统一 的 交互 类 ) | 
BlockManager。BlockManager 在 每 一 个 结 点 (包括 Driver 端 和 Slave 端 ) 都 有 创建 。Slave 端 
创建 的 BlockManager 将 在 initialize 方法 中 向 Driver 端的 BlockManagerMasterEndpoint 发 送 Reg- < 
isterBlockManager (blockManagerId，maxMemSize ，slaveEndpoint ) 消息 ， 收 到 消息 后 ， 完 成 
Slave 端 BlockManager 在 Driver 端 BlockManager 的 注册 。 如 图 6-2 所 示 。 
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6-2 ”Storage 模块 通信 层 


Driver 端的 BlockManagerMaster 拥有 所 有 结 点 BlockManagerSlaveEndpoint 的 Ref 及 Block- 
ManagerMasterEndpoint 的 引用 。Slave 端的 BlockManagerMaster 拥有 本 结 点 上 所 有 BlockMan- 
agerSlaveEndpoint 的 Ref。Driver 和 各 结 点 通过 BlockManagerMasterEndpoint 和 BlockManagerS- 
laveEndpoint 通信 。 

在 Driver 和 Slaves 结 点 上 的 Executor 中 都 有 BlockManager。BlockManager 提供 了 本 地 和 
远程 不 同 存储 类 型 (Disk 、Memory 、ExternalBlockStore ) 存储 读 取 数据 的 接口 。 

首先 来 看 一 下 BlockManager 在 Driver 端的 创建 。 在 SparkContext 创建 时 会 根据 具体 的 配 
置 创建 SparkEnv 对 象 。 源 代码 如 下 所 示 。 
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2 
3 
4. 
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内 核 机 制 解析 及 性 能 调 优 


private| spark | def createSparkEnv( 
conf: SparkConf, 


isLocal: Boolean, 
listenerBus : LiveListenerBus ) :SparkEnv = | 


// 创 建 Driver 端的 运行 环境 





. SparkEnv. createDriverEnv( conf, isLocal ,listenerBus, SparkContext. numDriverCores( master ) ) 


| 


在 createSparkEnv 方法 中 传人 SparkConf 配置 对 象 、isLocal 标志 及 LiveListenerBus ， 方 法 
中 使 用 SparkEnv 对 象 的 createDriverEnv 方法 创建 SparkEnv 并 返回 。 在 SparkEnv 的 creat- 
eDriverEvn 方法 中 ,将 会 创建 BlockManager、BlockManagerMaster 等 对 象 ， 完 成 Storage 在 
Driver 端的 部 署 。 

SparkEnv 中 创建 BlockManager 和 BlockManagerMaster 的 关键 源 代码 如 下 所 示 。 


AR SC 


呈 





// 创 建 BlockManagerMaster 

val block ManagerMaster = new BlockManagerMaster( registerOrLookupEndpoint( 
BlockManagerMaster. DRIVER_ENDPOINT_NAME， 

// 创 建 BlockManagerMasterEndpoint 

new BlockManagerMasterEndpoint( rpcEnv,isLocal ,conf, listenerBus ) ) ， 

conf ,isDriver ) 

// 创 建 BlockManager 

val block Manager = new BlockManager( executorld ,rpcEnv, block ManagerMaster, 
serializer, conf, memoryManager, mapOutputTracker, shuffleManager, 


blockTransferService , securityManager, numUsableCores ) 





上 面 代码 的 第 2 行使 用 new 关键 字 实 例 化 出 BlockManagerMaster， 并 在 代码 第 8 行 传人 
BlockManager 的 构造 图 数 ， 实 例 化 出 BlockManager 对 象 。 这 里 的 BlockManagerMaster 和 
BlockManager 属于 聚合 关系 。BlockManager 主要 对 外 提供 统一 的 访问 接口 ，BlockManager- 
Master 主要 对 内 提供 各 结 点 之 间 的 指令 通信 服务 。 

BlockManagerMaster 在 Driver 端 和 Executors 中 的 创建 稍 有 差别 。 首 先 来 看 在 Driver 端 创 
建 的 情形 。 创 建 BlockManagerMaster 传人 的 isDriver 参数 ，isDriver 为 true 表示 在 Driver 端 创 
建 ， 否 则 视 为 在 Slave 结 点 上 创建 。 

当 SparkContext 中 执行 _env. blockManager. initialize( _applicationId ) 代码 时 ， 会 调用 Driver 
端 BlockManager 的 initialize 方法 。initialize 方法 的 源 代码 如 下 所 示 。 














1. def initialize( appId:String) :Unit = | 


2 


CE 














// 调 用 blockTransferService 的 initialize 方法 ,blockTransferService 用 于 在 不 同 结 点 fetch 数 
据 ,传送 数据 

blockTransferService. init(this ) 

//shuffleClient 用 于 读 取 其 他 Executor 上 的 shuffle files 

shuffleClient. init(appId ) 

// 得 到 blockManagerld 
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路 blockManagerld = Block Managerld( 
executorld , blockTransferService. hostName , blockTransferService. port) 
9. // 得 到 | shuffleServerld 
10. shuffleServerld = if( externalShuffleServiceEnabled ) | OO 
11. logInfo( s" external shuffle service port = $ externalShuffleServicePort" ) 
2 BlockManagerld ( executorld ,blockTransferService. hostName ,externalShuffleServicePort ) 


lS | else | 
14. blockManagerld 
15. } 


16. /向 blockManagerMaster 注册 BlockManager。 在 registerBlockManager 方法 中 信 并 于 
slaveEndpoint ,slaveEndpoint 为 BlockManager 中 的 RPC 对 象 ,用 于 与 blockManagerMaster 进行 


通信 






































[Ik master. registerBlock Manager( block Managerld, maxMemory , slaveEndpoint ) 
18. // 注 册 shuffleServer 


19. DWif( externalShuffleServiceEnabled &&! blockManagerld. isDriver) | 
20. registerWithExternalShuffleServer( ) 

2 } 

2 


如 上 面 的 源 代码 所 示 ，initialize 方法 使 用 appId 初始 化 BlockManager。 主 要 完成 以 下 几 
项 任务 。 

1) 初始 化 BlockTransferService。 

2) 初始 化 ShuffleClient。 

3) 创建 BlockManagerld。 

4) 将 BlockManager 注册 到 BlockManagerMaster 上 。 

5) 若 ShuffleService 可 用 ， 注册 ShuffleService。 

在 Block Manager 的 initialize 方法 上 右 击 Find Usages, 可 以 看 到 initialize 方法 在 两 个 地 方 
得 到 调用 ， 一 个 是 SparkContext， 男 一 个 是 Executor。 在 启动 Executor 时 ， 会 调用 BlockMan- 
ager 的 initialize 方法 。Executor 中 调用 initialize 方法 的 源 代 码 如 下 所 示 。 





























1. //CoarseGrainedExecutorBackend 中 实例 化 Executor,isLocal 设置 成 false, 即 Executor 中 的 isLo- 
cal 始终 为 fasle 


























2. if(! isLocal) | 

3. /向 度量 系统 注册 

4. env. metricsSystem. registerSource( executorSource ) 

5. // 调 用 BlockManager 的 initialize 方法 ,如 前 所 述 , initialize 方法 将 向 BlockManagerMaster 注 
册 , 完 成 Executor 中 的 BlockManager 向 Driver 中 的 BlockManager 的 注册 

6. env. blockManager. initialize( conf getAppld) 

7 


上 面 代码 中 ， 调 用 了 env. block Manager. initialize 方法 。 在 initialize 方法 中 ， 完 成 Block- 
Manger 向 Master 端 BlockManagerMaster 的 注册 。 使 用 方法 master. registerBlockManager ( block- 









内 核 机 制 解析 及 性 能 调 优 


Managerld , maxMemory , slaveEndpoint ) 完成 注册 ，registerBlockManager 方法 中 传人 blockMan- 
agerId 、maxMemory 和 salveEndPoint 引用 ， 分 别 表 示 Executor 中 的 BlockManager 、 最 大 内 存 
和 BlockManger 中 的 BlockMangarSlaveEndpoint。BlockManagerSlaveEndpoint 是 一 个 RPC 端点 ， 
通过 它 完成 与 BlockManagerMaster 的 通信 。BlockManager 收 到 注册 请 求 后 将 Executor 中 注册 
的 BlockManagerInfo 存 人 哈 希 表 中 ， 以 便 通 过 BlockManagerSlaveEndpoint 向 Executor 发 送 控 


制 命令 。 











存储 层 











Storage 的 存储 由 统一 接口 BlockStore 定义 ，BlockStore 是 一 个 抽象 类 ， 定 义 了 数据 的 读 
写 方法 。BlockStore 抽象 类 有 不 同 的 实现 ， 目 前 有 DiskStore 、MemoryStore 、ExternalBlockStore 
三 种 不 同 的 实现 。 下 面 是 BlockStore 抽象 接口 的 定义 。 


1. private| spark | abstract class BlockStore( val blockManager:BlockManager) extends Logging | 

2. ” // 通 过 指定 的 StorageLevel, 存 人 字 节 数组 

3. def putBytes( blockld: BlocklId ,bytes: ByteBuffer, level: StorageLevel) :PutResult 

4. // 通 过 指定 的 StorageLevel, 存 入 任意 类 型 的 的 数据 values ,前 提 是 values 是 可 迭代 的 ,return- 
Values 用 于 指定 是 否 返 回 值 

5. def putlterator ( blockId: Blockld, values: Iterator| Any | , level: StorageLevel, returnValues: Boole- 
an) : PutResult 

6. // 通 过 指定 的 StorageLevel, 存 人 任意 类 型 的 数据 ,这 些 数据 是 放 入 数组 中 的 ,returnValues 用 

于 指定 是 否 返 回 值 


7. def putArray( blockId :BlockId ,values : Array[ Any | , level: StorageLevel ,returnValues:Boolean ) : 























PutResult 
8. /得 到 blockId 对 应 的 数据 集合 的 大 小 
9. def getSize( blockId:BlockId) :Long 
10. // 得 到 blockId 对 应 的 数据 集合 的 数据 ,返回 类 型 是 Option[ ByteBuffer] 
11. def getBytes( blockId:BlockId) : Option| ByteBuffer | 
12. /得 到 blockld 对 应 的 数据 ,返回 类 型 是 Iterator[ Any] 
13. def getValues(blockId:BlockId) :Option[ lterator[ Any | | 
14. // 移 除 blockId 对 应 的 数据 , 移 除 成 功 返 回 true 
15. def remove( blocklId: Blockld ) :Boolean 
16. ”DiskStore 中 是 否 包含 blockId 对 应 的 数据 
ys def contains( blockId :BlockId ) : Boolean 
18. ”用 于 清除 数据 
19. def clear( ) | |} 
20. | 








上 面 源 代码 是 BlockStore 抽象 类 的 定义 。putBytes 、putIterator 、putArray 三 个 接口 方法 类 
似 ， 都 是 按照 指定 的 存储 级 别 存 储 集合 字 节 信息 ， getSize 方法 返回 指定 blockId 对 应 数据 块 
的 长 度 ，getBytes 返回 指定 blockld 对 应 的 数据 块 的 字 节 数组 。remove 方法 移 除 指定 blockId 
对 应 的 数据 ， 若 该 blockld 存在 并 且 移 除 成 功 ， 返回 true， 否 则 返回 false。Contains 方法 用 于 
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判断 blockId 对 应 的 数据 是 否 存 在 。clear 方法 是 一 个 钓 子 方法 ， 在 DiskStore 和 ExternalBlock- 
Store 中 不 做 任何 处 理 ， 在 MemoryStore 中 用 于 清除 内 存 中 的 MemoryEntry， 用 于 释放 内 存 
空间 。 
Storage 存储 按 BlockStore 的 实现 分 为 三 种 情况 : O) 
1) DiskStore: 存储 数据 到 磁盘 。 
2) MemoryStore: 以 字 节 数组 或 Java 对 象 的 方式 存储 在 内 存 中 。 
3) ExternalBlockStore: 存储 数据 到 OFF_HEAP 中 ，Spark 目前 的 OFF_HEAP 默认 实现 采 
用 Tachyon。 
BlockStore 是 存储 模块 的 抽象 ， 提 供 了 存 取 数 据 的 基本 的 抽象 方法 。DiskStore 、Memo- 
ryStore 、ExternalBlockStore 都 实现 BlockStore 接口 ， 它 们 的 继承 层次 类 图 如 图 6-3 所 示 。 








ExternalBlockStore 





—- executorld : String 

















oOo- BlockStore 

+ blockManager : BlockManager 

+ putlterator () : PutResult 

+ putArray () : PutResult 

+ putBytes () : PutResult 

+ getSize © Ong 

+ getBytes () : Option[ByteBuffei 

+ getValues (0 : Option[Iterator[! 

+ remove () : boolean 

+ contains () : boolean 

站 E VAN 四 1 

DiskStore MemoryStore 

— diskManager : DiskBlc — memoryManager : Memory 











图 6-3 ”BlockStore 的 继承 结构 





使 用 BlockStore 时 ， 可 以 指定 StorageLevel ，StorageLevel 中 存放 的 是 一 些 标 志 信 息 ， 这 
些 标志 信息 用 于 判断 RDD 数据 进行 何 种 方式 的 存储 。 下 面 是 StorageLevel 的 部 分 源 代 码 。 





class StorageLevel private( 

// 是 否 使 用 磁盘 

private var_useDisk :Boolean ， 
// 是 否 使 用 内 存 

private var_useMemory: Boolean, 
// 是 否 使 用 OFF_HEAP 

private var_useOffHeap: Boolean, 
// 是 否 序 列 化 

private var_deserialized : Boolean, 


10，// 副 本 个 数 ,默认 为 1 


0 A dl ee 
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Private var_replication: Int =1) 


extends Externalizable | 
// 下 面 是 Spark 中 一 些 预定 义 好 的 存储 级 别 ,这 些 存 储 级 别 可 以 满足 几乎 所 有 场景 需求 
// 不 设置 存储 级 别 
val NONE = new StorageLevel( false ,false ,false , false ) 
// 只 是 用 磁盘 

val DISK_ONLY = new StorageLevel( true ,false ,false ,false ) 
// 只 是 用 磁盘 ,并 且 副 本 个 数 设 置 为 2 

val DISK_ONLY_2 = new StorageLevel( true , false , false , false ,2) 
// 只 是 用 内 存 

val MEMORY_ONLY = new StorageLevel( false ,true , false ,true ) 
// 只 是 用 内 存 ,副本 个 数 为 2 

val MEMORY_ONLY_2 = new StorageLevel(false ,true ,false ,true ,2) 
// 只 是 用 内 存 并 且 序列 化 数据 ,这 些 数据 以 字 节 数组 的 形式 存放 于 内 存 中 ,大 大 减 小 内 存 
中 对 象 的 个 数 和 占用 内 存 的 空间 ,但 是 需要 额外 的 序列 化 和 反 序列 化 性 能 开销 

val MEMORY_ONLY_SER = new StorageLevel( false ,true , false , false ) 
// 只 是 用 内 存 并 且 序 列 化 ,设置 副本 个 数 为 2。 这 些 数据 以 字 节 数组 的 形式 存放 于 内 存 中 ， 
大 大 减 小 内 存 中 对 象 的 个 数 和 占用 内 存 的 空间 ,但 是 需要 额外 的 序列 化 和 反 序 列 化 性 能 
开销 

val MEMORY_ONLY_SER_2 = new StorageLevel(false ,true,false,false,2) 
// 使 用 内 存 和 磁盘 进行 存储 ,Spark Executor 中 默认 用 于 存储 的 内 存 的 大 小 为 Executor 分 配 
内 存 的 3Z8 ,超出 该 设置 的 大 小 ,数据 将 外 溢 到 磁盘 

val MEMORY_AND_DISK = new StorageLevel(true ,true ,false,true) 
// 使 用 内 存 和 磁盘 进行 存储 ,设置 副本 个 数 为 2。Spark Executor 中 默认 用 于 存储 的 内 存 的 
大 小 为 Executor 分 配 内 存 的 3/8, 超 出 该 设置 的 大 小 ,数据 将 外 洲 到 磁盘 

val MEMORY_AND_DISK_2 = new StorageLevel( true ,true ,false , true ,2) 
// 使 用 内 存 和 磁盘 并 序列 化 存储 。Spark Executor 中 默认 用 于 存储 的 内 存 的 大 小 为 Executor 
分 配 内 存 的 3/8 ,超出 该 设置 的 大 小 ,数据 将 外 湾 到 磁盘 。 

val MEMORY_AND_DISK_SER = new StorageLevel(true ,true , false , false ) 
// 使 用 内 存 和 磁盘 并 序列 化 存储 ,副本 个 数 为 2。Spark Executor 中 默认 用 于 存储 的 内 存 的 
大 小 为 Executor 分 配 内 存 的 3/8, 超 出 该 设置 的 大 小 ,数据 将 外 洲 到 磁盘 

val MEMORY_AND_DISK_SER 2 = new StorageLevel( true ,true ,false , false ,2) 
// 使 用 OFF_HEAP,Spark 中 目前 使 用 Tachyon 实现 OFF_HEAP 存储 

val OFF_HEAP = new StorageLevel( false ,false ,true ,false) 




































































StorageLevel 的 几 个 构造 参数 是 _useDisk、_useMemory、_useOffHeap、_ deserialized 、 
_replication。 在 构建 StorageLevel 的 时 候 ， 根 据 传 人 参数 的 不 同 ， 实 例 化 出 不 同 的 StorageLev- 
el。 在 Spark 中 已 经 预先 定义 出 了 很 多 StorageLevel， 例 如 DISK_ONLY、MEMORY_ONLY 等 ， 
这 些 预定 义 的 存储 级 别 可 以 直接 通过 StorageLevel 对 象 引 用 ， 并 且 这 些 预定 义 的 存储 级 别 几 
乎 能 满足 所 有 存储 情景 。 

下 面 分 别 对 BlockStore 的 三 种 不 同 实现 ; DiskStore 、MemoryStore 、ExternalBlockStore 存 
储 数据 进行 讲解 。 
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1. DiskStore 

顾名思义 ，DiskStore 会 将 Block 存放 到 磁盘 上 ， 要 存储 数据 就 需要 指定 数据 存放 的 路 
径 ， 怎 么 设置 存放 Block 的 路 径 呢 ?在 DiskStore 中 可 以 配置 多 个 存放 Block 的 目录 ，Disk- 
BlockManger 会 根据 这 些 配置 创建 不 同 的 文件 夹 ， 存 放 Block。 文 件 夹 的 命名 格式 为 prefix - > 
UUID 的 形式 ，Prefix 为 指定 的 文件 名 前 缀 (默认 为 blockmgr) ，UUID 为 UUID 算法 生成 的 字 
符 串 ，Block 将 会 存放 在 所 有 的 创建 目录 中 并 保存 副本 。DiskBlockManger 会 调用 createLo- 
calDirs 方法 为 Block 创建 文件 夹 ， 源 代码 如 下 。 





1. private def createLocalDirs( conf:SparkConf) :Array[ File | = | 

外 // 从 SparkConf 配置 对 象 中 找 出 配置 的 文件 保存 路 径 ,配置 项 为 spark. local. dir, 路 径 可 以 
配置 多 个 ,用 逗号 分 隔 开 

3: Utils. getConfiguredLocalDirs( conf). flatMap | rootDir => 

4. try | 

Ss // 调 用 Utils 的 createDirectory 方法 ， 创建 目录 ,该 方法 返回 创建 好 的 目录 localDir, 该 方法 
接受 两 个 参数 ,第 一 个 参数 是 要 创建 的 目录 的 路 径 , 第 二 个 参数 是 创建 目录 的 前 绥 






















































































6 val localDir = Utils. createDirectory( rootDir," blockmgr" ) 
A logInfo( s" Created local directory at $ localDir" ) 

8 // 返 回 创建 好 的 目录 

9 Some( localDir) 

10. | catch | 

11. case e:IOException => 

2 logError( s" Failed to create local dir in $ rootDir Ignoring this directory. " ,e) 
13. None 

14. } 

Ss } 

16. | 


上 面 代码 中 ， 传 人 SparkConf， 通 过 Utils 得 到 conf 中 配置 的 多 个 文件 的 根 目录 ， 并 使 用 
Utils. createDirectory ( rootDir," blockmgr" ) 方法 实际 创建 根 目 录 ,， 这 些 目 录 可 以 通过 
spark. local. dir 配置 项 配置 。 下 面 是 Utils 的 createDirectory 方法 的 源 代 码 。 











1. /7/ 该 方法 在 给 定 的 root 目录 下 创建 子 目录 
2. def createDirectory(root:String,namePrefix:String = " spark" ) :File = | 
3 // 定 义 变量 ,表示 尝试 创建 目录 的 次 数 
4 var attempts =0 

5. /最 大 尝试 次 数 ,默认 为 10 次 
0 val maxAttempts = MAX_DIR_CREATION_ATTEMPTS 
7 

8 

9 


var dir: File = null 








// 只 要 dir 为 null ,一直 循环 尝试 创建 目录 ,直到 最 大 尝试 次 数 
while( dir == null) | 

10. // 尝 试 次 数 加 1 

le attempts += 1 
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12. // 尝 试 创建 目录 的 次 数 大 于 最 大 尝试 次 数 , 抛 出 IOExcetion 异常 

Ta， if(attempts > maxAttempts ) | 

14. throw newIOException("Failed to create a temp directory( under" + root +" ) after'" + 

15. ImaxAttempts + " attempts!" ) 

16. | 

17. // 尝 试 在 给 定 的 根 目录 下 创建 以 namePrefix 为 前 级 ,以 UUID 产生 的 UUID 字符 串 结尾 
的 目录 

18. try | 

19. // 得 到 目录 对 应 的 File 对 象 

20. dir = new File( root, namePrefix +" -" + UUID. randomUUID. toString) 

21. [/[ 若 Mar 已 经 存在 ,或 者 不 能 创建 该 目录 , 置 dir 为 null 

2 if( dir. exists( ) 11! dir mkdirs( ) ) | 

238 dir = null 

24. } 

25: | catch | case e:SecurityException => dir = null; |// 若 没有 权限 创建 目录 ,捕获 Securi- 
tyException 异常 消息 

26. } 

27. /返回 标准 的 创建 文件 夹 的 路 径 

28. dir. getCanonicalFile 

29 























上 面 源 代码 中 有 一 个 attempts 变量 ， 用 于 记录 尝试 创建 文件 夹 的 次 数 ， 如 果 dir 文件 夹 





为 空 将 会 一 直 循 环 处 理 ， 直到 attempts 达到 最 


尝试 次 数 为 止 。 如 果 超 过 最 大 创建 文件 夹 


的 次 数 ， 将 会 抛 出 IOExeception 异常 。 创 建文 件 夹 将 会 以 传人 的 rootDir 为 根 路 径 ， 创 建文 件 


夹 的 格式 为 prefix 











+"-"+UUID. randomUUID. toString 的 形式 ， 如 果 dir 存在 或 者 不 能 够 创建 
目录 ， 则 将 dir 置 为 aull。 若 没有 创建 目录 的 权限 ， 将 捕获 SecurityException 异常 ， 异 常 处 理 





也 是 将 dir 置 空 5 





重新 进行 while 循环 。 


在 DiskBlock 存储 中 ， 逻 辑 意 义 上 的 block 和 文件 有 什么 关系 呢 ? 在 DiskBlock 中 ， 每 一 
个 Block 都 被 存储 为 一 个 文件 ,文件 的 名 称 是 通过 计算 BlockId 对 象 中 的 外 eName 的 哈 希 值 
得 到 的 ， 通 过 映射 得 到 文件 名 称 之 后 ， 将 block 中 的 数据 写 人 到 文件 中 。BlockId 对 象 中 的 
fileName 与 文件 路 径 映 射 关 系 的 源 代 码 如 下 所 示 。 








def getFile(filename:String) :File = | 
由 包 eName 计算 出 hash 值 


2 
val 


76 


ZY 


val 


2 


IR 
之 
3 
4 
Sk val 
6 
% 
8 
9 


hash = Utils. 


nonNegativeHash (filename) 





使 用 非 负 哈 希 值 余 上 localDirs 的 长 度 , 得 到 目录 的 id 


dirld = hash 


% localDirs. length 








使 用 非 负 哈 希 值 和 localDirs 做 商 , 结 果 再 与 subDirsPerLocalDir 做 余 运 算 , 求 得 子 





subDirld = (hash / localDirs. length ) % subDirsPerLocalDir 
1 果子 目录 不 存在 , 则 创建 子 目录 


val subDir = subDirs( dirId ). synchronized | 
val old = subDirs( dirId) ( subDirId ) 


10. 





目录 id 
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11. if(old! =null)| 

1 // 如 果 存 在 , 则 直接 返回 subDir 

13. old 

14. | else | OO 
15. // 如 果 不 存在 , 则 创建 subDir 

16. val newDir = new File( localDirs( dirld) ," %02x". format( subDirld ) ) 
17. // 藻 newDir 不 存在 或 者 不 能 创建 目录 , 则 抛 出 IOException 异常 

18. if( | newDir exists( ) &&! newDir mkdir( ) ) | 

19. throw new IOException( s" Failed to create local dir in $ newDir.") 
20. | 

21. // 将 二 维 数组 subDirs 的 dirld 行 subDirId 的 值 设置 成 newDir 

2 subDirs( dirId ) (subDirId) = newDir 

2 // 返 回 newDir 

24. newDir 

25. | 

26. } 








2 // 返 回 以 subDir 为 根 目 录 ,filename 作为 文件 名 称 的 File 对象 
28. new File( subDir ,filename ) 
29. | 


getFile 方法 首先 得 到 fleName 的 哈 希 值 ， 用 哈 硕 值 对 localDirs 数组 长 度 做 模 运 算 ， 得 到 
要 存放 数据 的 目录 ID， 用 hash 值 对 localDirs 数组 长 度 做 除 运算 ， 结 果 对 subDirsPerLocalDir 
做 模 运 算得 到 存放 数据 的 目录 中 子 目 录 的 ID。 其 中 ，subDirsPerLocalDir 的 个 数 是 通过 
spark. diskStore. subDirectories 配置 项 配置 的 ， 默 认 值 为 64。 如 果 没 有 子 目 录 ， 则 创建 子 目 
录 ; 如 果 有 则 直接 返回 ，subdirs(i) 有 sbudirs(i) 锁 保 护 ， 防 止 由 于 多 线程 的 同时 修改 而 造成 
数据 的 不 一 致 。 使 用 哈 希 映射 将 文件 分 配 到 不 同 的 目录 的 目的 是 为 了 避免 顶级 目录 的 inodes 
过 于 庞大 。 

DiskStore 实现 了 BlockManager 中 存 取 block 的 方法 ， 这 里 以 BlockStore 抽象 类 中 的 put- 
Bytes( blockId : BlockId ， bytes: ByteBuffer , level: StorageLevel ) 为 例 ，DiskStore 重 写 的 putBytes 
方法 的 源 代码 如 下 。 





















































1. override def putBytes( blockId:BlockId ，bytes :ByteBuffer ,level :StorageLevel) :PutResult = | 
多 // 得 到 bytes 的 副本 

3 val bytes = _bytes. duplicate( ) 

4. logDebug(s" Attempting to put block $ blockId" ) 
5 上 /开始 时 间 

6 

% 


val startTime = System. currentTimeMillis 














// 调 用 getFile 方法 ,通过 哈 希 映射 得 到 对 应 的 文件 ,这 里 的 blockId 是 通过 CacheManager 
的 getOrCompute 方法 得 到 的 , getOrCompute 方法 中 有 这 样 的 代码 : val key = RDDBlockId 
(rdd. id ,partition. index) ,这 里 的 key 为 通过 RDD 的 id 和 RDD 分 区 的 索引 得 到 的 BlockId ,将 
RDD 中 的 partition 转化 为 Storage 模块 中 的 Block ,具体 转换 可 以 查看 BlockId 类 中 的 RDD- 
BlockId 用 例 类 
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8. val file = diskManager. getFile( blockId ) 
9. // 使 用 nio, 得 到 文件 上 的 channel 通道 




















10. val channel = new FileOutputStream( file ). getChannel 

11. Utils. tryWithSafeFinally | 

12. while( bytes. remaining >0) | 

13. // 将 bytes 数据 写 入 通道 

14. channel. write( bytes) 

15. | 

16. | 

17. /关闭 通道 

18. channel. close( ) 

19. } 

20. /得 到 完成 时 间 

2 val finishTime = System. currentTimeMillis 

228 logDebug( " Block %s stored as %s file on disk in %d ms". format( 
238 file. getName , Utils. bytesToString( bytes. limit) ,finishTime - startTime ) ) 


24. // 返 回 一 个 PutResult 对 象 ,该 对 象 携带 以 下 信息 。 

25. /1. 输入 数据 的 估计 大 小 

26.  /[2. 返回 放 入 的 数据 

DE //3. 因此 次 Put 数据 而 不 得 不 drop 掉 的 block 列表 ,在 DiskStore 中 ,永远 为 空 
28. PutResult( bytes. limit( ) , Right( bytes. duplicate( ) ) ) 

29. | 








上 面 源 代码 中 ，putBytes 方法 传人 blockId、_bytes 和 level 共 3 个 参数 ，blockId 代表 
BlockId 对 象 ， 该 对 象 中 有 一 个 全 局 唯一 的 name 属性 ; _bytes 是 ByteBuffer 类 型 ， 里 面 存放 
的 是 字 节 数据 ; level 表示 StorageLevel， 代 表 存 储 级 别 。 

putBytes 方法 中 通过 调用 diskManager 的 getFile (blockId) 方法 ， 得 到 BlockId 对 象 中 
fileName 映射 的 旬 e 路 径 ， 然 后 通过 该 路 径 得 到 File 对 象 ， 再 使 用 File 对 象 上 的 输出 流通 
道 向 文件 中 写 入 字 节 数据 ， 最 后 返回 PutResult 对 象 ， 它 是 一 个 携带 此 次 put 操作 数据 信息 
的 对 象 。 

Block 数据 存 人 DiskStore 之 后 ， 要 怎么 读 取 这 些 宝贵 的 数据 呢 ? 其 实 想 要 读 取 DiskStore 
中 的 block 数据 很 简单 ， 只 需 通过 BlockId 对 象 的 包 eName 属性 获得 对 应 的 哈 希 映射 文件 ， 
并 从 文件 中 读 取 数据 即 可 。 下 面 来 看 一 下 DiskStore 的 getBytes( blockId : BlockId ,offSet: Long， 
length : Long) 方法 源 代码 如 下 。 









































1. override def getBytes( blockId: BlockId) :Option[ ByteBuffer | = | 

2 // 通 过 diskManager 的 getFile 方法 ,通过 计算 blockId 中 name 属性 的 哈 希 值 匹配 到 文件 

3. val file = diskManager. getFile( blockId. name) 

A // 将 blockld 对 应 的 文件 传人 getByte (file,0,file. length ) 方法 中 ,该 方法 放 回 Option 
[ ByteBuffer | 

S getBytes( file,0 ,file. length ) 
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6. | 

7. private def getBytes(file:File,offset:Long,length:Long) :Option[ ByteBuffer] = | 
8 

9 





// 以 只 读 的 形式 获得 fle 上 的 channel 通道 
. val channel = new RandomAccessFile(file,"r" ). getChannel O) 
10. Utils. tryWithSafeFinally | 
11. // 对 于 小 文件 ,直接 读 取 ,不 适用 内 存 映 射 
























































开交 // 文 件 长 度 小 于 minMemoryMapBytes, 直接 读 取 。minMemoryMapBytes 的 默认 大 小 
为 2M 

13. if(length < minMemoryMapBytes ) | 

14. // 使 用 ByteBuffer 的 allocate 方法 ,创建 长 度 为 length 的 字 节 缓存 数组 

Sa val buf = ByteBuffer. allocate( length. toInt) 

16. // 设 置 读 写 文件 的 起 始 位 置 为 offset 处 ,此 处 为 0, 表 示 文 件 开始 

17. channel. position ( offset ) 

18. // 当 buf 中 还 有 字 节 

19. while( buf. remaining( )! =0) | 

20. // 从 channel 中 顺序 读 取 一 个 字 节 放 入 buf, 背 读 到 -1, 抛 出 IOException 异常 

2 if( channel. read( buf) == —1)| 

2 throw newIOException( " Reached EOF before filling buffer\n" + 

238 s" offset = $ offset \ nfile = $ |file. getAbsolutePath} \ nbuf. remaining = $ 
| buf. remaining} " ) 

24. | 

25. | 

26. /人 /翻转 数组 

Ys 

28. 

29. 

30. buf flip( ) 

31. /人 /返回 字 节 缓存 数组 

3 站 Some( buf) 

33. | else | 

34. // 通 过 channel 上 的 map 方法 ,以 内 存 映射 的 方式 读 取 文 件 内 容 

3 Some( channel. map( MapMode. READ_ONLY ,offset ,length) ) 

36. } 

3 | 

38. /关闭 通道 

39. channel. close( ) 

40. } 

41. |} 





getBytes( blockId :BlockId ) 方 法 中 ， 通 过 BlockId 对 象 中 的 name 属性 ， 由 哈 希 算法 获取 
映射 的 文件 并 通过 getBytes (file: File , offSet: Long, length: Long) 读 取 Block 映射 文件 中 的 字 
节 数 据 。 对 于 小 于 2 MB 的 文件 ， 采 用 直接 读 取 的 方式 ; 对 于 大 于 2 MB 的 文件 ， 采 用 内 存 映 
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射 的 方式 读 取 。 内 存 映射 方式 可 以 大 大 提高 读 取 数据 的 性 能 ， 尤 其 适合 读 取 大 文件 ， 这 里 的 
minMemoryMapBytes 取 值 默认 为 2 MB。 

从 getBytes 和 putBytes 两 个 方法 的 分 析 中 可 以 看 到 ， 在 DiskStore 中 读 取 和 保存 block 都 
是 先 通 过 Blockld 获得 映射 的 文件 ， 然 后 通过 数据 流 的 形式 读 取 和 保存 文件 的 。 

DiskStore 会 将 数据 保存 到 磁盘 ， 如 果 频 繁 地 对 磁盘 进行 LO 操作 ， 必 将 严重 影响 系统 的 
性 能 ， 正 好 MemoryStore 可 以 解决 对 磁盘 的 IO 操作 带 来 的 问题 ， 由 于 MemoryStore 数据 是 

驻 留 在 内 存 中 的 ， 可 以 直接 从 内 存 中 读 取 数 据 ， 减 少 磁 盘 LO， 大 大 加 快 了 数据 的 读 写 速 

， 因 此 MemoryStore 可 以 给 系统 性 能 带 来 巨大 的 提升 。 下 面 就 来 看 看 MemoryStore 的 源 代 
码 实现 ，MemoryStore 与 DiskStore 最 大 的 不 同 是 MemoryStore 将 block 保存 在 内 存 中 ， 而 Disk- 
Store 将 block 通过 文件 的 形式 保存 在 磁盘 中 。 

2. Memory Store 

MemoryStore 中 维护 着 一 个 LinkedHashMap 来 管理 所 有 的 Block ，Block 被 包装 成 Memory- 





Entry 对 象 ， 























该 对 象 中 保存 了 Block 相关 的 数据 信息 ， 如 大 小 、 是 否 反 序列 化 等 。Link- 





endHashMap 以 blockId 作为 键 ，blockId 对 应 的 MemoryStore 作为 值 ， 其 源 代码 的 定义 如 下 。 


. // 链 表 类 型 的 哈 希 es 它 保留 了 数据 插入 的 顺序 ,构造 LinkedHashMap 时 传人 3 个 参数 ,第 


一 个 参数 表示 初始 化 容量 ,这 里 取 值 为 32 ,第 二 个 参数 表示 负荷 系数 ,这 里 取 值 0. 75 ,容量 
过 32 x0.75 =24 个 时 ,自动 扩容 。 第 三 个 参数 表示 访问 模型 ,true 表示 访问 顺序 ,false 表示 插 
入 顺序 








. private val entries = new LinkedHashMap[ BlockId ,MemoryEntry | ( 32 ,0. 75f, true) 


3. //MemoryEntry 用 例 类 


4. 


private case class MemoryEntry( value: Any ,size: Long, deserialized : Boolean ) 


MemoryStore 中 必须 要 有 足够 的 内 存 来 存放 Block， 和 否则 将 会 把 Block 溢出 到 磁盘 文件 中 。 
下 面 以 putBytes 方法 为 例 ， 源 代码 如 下 。 


1 
之 
3 
4 
0 
也 
8 
9 





. override def putBytes( blockId:BlockId，bytes:ByteBuffer ,level:StorageLevel) :PutResult = | 


// Work on a duplicate - since the original input might be used elsewhere. 
// 得 到 _bytes 的 副本 
val bytes = _bytes. duplicate( ) 
// Rewinds this buffer The position is set to zero and the mark is discarded. 
bytes. rewind( ) 
// 判 断 是 否 反 序列 化 
if( level. deserialized ) | 
// 反 序列 化 字 节 数组 为 可 迭代 的 value 
val values = block Manager. dataDeserialize( blockId ,bytes ) 
// 调 用 putlterator 方法 


putlterator( blockld ,values ,level , returnValues = true) 





| else | 
// 需 要 洪 出 的 block 数组 ,数组 中 存放 的 是 (Blockld,BlockStatus) 二 维 元 组 
val droppedBlocks = new ArrayBuffer[ (BlockId ,BlockStatus ) | 
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16. // 调 用 tyToPut 方法 ,尝试 put 操作 , 若 内 存 中 不 能 存放 , 则 溢出 到 磁盘 

7k tryToPut( blockId ,bytes , bytes. limit ,deserialized = false,droppedBlocks ) 

18. PutResult( bytes. limit( ) ,Right(bytes. duplicate( ) ) ,droppedBlocks ) 

a O) 
20. | 


putBytes 方法 中 包含 BlockId、ByteBuffer 、StorageLevel 共 3 个 参数 ， 这 3 个 参数 的 含义 
与 DiskStore 中 putBytes 参数 一 样 。 代 码 行 中 ， 通 过 duplicate 方法 得 到 _bytes 的 副本 3 以 避免 
在 多 个 地 方 修改 一 个 变量 ， 造 成 逻辑 上 的 错误 。 接 下 来 判断 StorageLevel 是 否 为 deserialized ， 
如 果 为 tue， 则 进行 反 序列 化 ， 将 字 节 数组 反 序列 化 成 可 迭代 的 对 象 ， 然 后 调用 putIterator 
方法 存 人 内 存 ; 若 deserialized 为 false， 则 调用 tryToPut 方法 尝试 将 字 节 数组 中 的 数据 存 人 内 
存 ，tryToPut 方法 的 源 代 码 如 下 。 


















































1. private def tryToPut( 

2 blockId: BlockId ， 

3. value:() => Any， 

4. size: Long, 

SE deserialized :Boolean ， 

6. droppedBlocks :mutable. Buffer[ (BlockId , BlockStatus) ] ) :Boolean = | 

A // 使 用 memoryManager 对 象 上 的 synchronized 同步 块 , 同 步 操 作 , 防 止 多 线程 访问 

8. memoryManager. synchronized | 

9. // 为 任务 释放 内 存 

10. releasePendingUnrollMemoryForThisTask( ) 

11. // 请 求 足够 的 内 存 ,用 于 存放 block 数据 

2 val enoughMemory = memoryManager. acquireStorageMemory ( blockId , size , droppedBlocks ) 

13. // 如 果 enoughMemory 为 true 

14. if( enoughMemory ) | 

LS: // 有 足够 的 内 存 ,用 block 数据 构建 MemoryEntry 对 象 

16. val entry = new MemoryEntry( value( ) , size, deserialized ) 

17. entries. synchronized | 

18. //entries 是 一 个 LinkedHashMap ,向 该 map 中 存 人 block 数据 信息 

19. entries. put( blockId ,entry ) 

20. } 

21. | else |// 如 果 内 存 不 足以 存放 下 block 信息 , 则 将 其 溢出 到 Disk Store, 前 提 是 允许 使 
用 DiskStore 

2 lazy val data = if( deserialized ) | 

23: Left( value( ). asInstanceOf[ Array[ Any] ] ) 人/ 若 deserialized 为 true ,将 values 转换 成 
Array 数组 

24. | else | 

2 Right( value ( ). asInstanceOf[ ByteBuffer]. duplicate( ) ) 人 /和 否则 ,将 value 作为 Byte- 
Buffer 实例 


26. | 
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2 // 调 用 blockManager 的 dropFromMemory 方法 ,将 block 数据 从 内 存 溢出 到 磁盘 
28. val droppedBlockStatus = blockManager. dropFrom Memory( blockld,( ) => data) 

29. droppedBlockStatus. foreach | status => droppedBlocks += ( (blockld ,status) ) } 

30. } 

31. // 返 回 内 存 是 否 满足 存储 的 标志 enoughMemory 

32. enoughMemory 

33. } 

3 


在 tryToPut 方法 中 ， 首 先 调用 MemoryManager 的 acquireStorageMemory 方法 ， 判 断 空闲 内 
存 是 否 足 以 容纳 block。 知 可 以 容纳 该 Block ， 则 将 该 Block 放 入 内 存 中 的 entries 这 个 Linked- 
HashMap 进行 管理 ; 若 不 足以 容纳 ， 则 通过 调用 dropFromMemory 方法 将 此 Block 溢出 到 
DiskStore。 

MemoryStore 将 Block 放 入 Executor 内 存 中 ， 每 一 个 独立 的 JVM 进程 都 可 以 分 配 堆 大 小 
( -Xmx 和 一 Xms)。Executor 详细 的 内 存 模型 分 析 在 6. 4 小 节 介 绍 。 

接 下 来 讲解 如 何 从 MemoryStore 中 读 取 Block 信息 。 从 MemoryStore 中 取得 Block 比较 简 
单 ， 根 据 blockId 从 哈 希 表 中 取出 即 可 。 这 里 以 MemoryStore 的 getValues 方法 为 例 ， 源 代码 
如 下 。 











1. override def getValues( blockId :BlockId) :Option| Iterator[ Any] ] = | 





2. // 通 过 entyies 这 个 LinkedHashMap 的 synchronized 同步 块 

3 val entry = entries. synchronized | 

4 // 取 出 blcokId 对 应 的 MemoryEntry 信息 

Sa entries. get( blockld) 

6. } 

7 if( entry == null) | 

8 // 共 entry 为 null ,返回 None 

9 None 

10. | else if(entry. deserialized ) | 

11. // 如 果 entry 的 deserialized 为 true ,将 value 转换 成 Array 数组 ,返回 数组 的 迭代 器 
12. Some( entry. value. asInstanceOf| Array[ Any | ]. iterator) 

3 | else | 

14. // 得 到 value 的 一 个 只 读 副本 ,类 型 为 ByteBuffer 

| val buffer = entry. value. asInstanceOf| ByteBuffer |. duplicate( )// Doesu t actually copy da- 
ta 

16. Some( block Manager. dataDeserialize(blockId , buffer ) ) 

ig } 

18. |} 





getVaults 方法 接受 blockId 作为 参数 ， 从 entries 这 个 LinkedHashMap 中 查找 ， 如 果 没 有 
查 到 该 blockId 对 应 的 MemoryEntry， 返 回 None， 奉 则 再 根据 是 否 反 序列 化 得 到 反 序 列 化 之 
后 的 数据 并 返回 。 
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Spark 中 有 3 种 BlockStore 的 实现 ， 分 别 是 DiskStore 、MemoryStore 和 ExternalBlockStore ， 
上 面谈 到 了 DiskStore 和 MemoryStore 中 存 取 block 的 操作 ， 接 下 来 看 一 下 ExternalBlockStore 
中 对 block 的 存 取 操作 。 
3. External BlookStore OO 
ExternalBlockStore 将 Block 存储 在 JVM 外 部 的 存储 系统 中 ，Spark 目前 实现 的 External- 
BlockStore 将 block 存放 在 Tachyon 分 布 式 内 存 文件 系统 中 。ExternalBlockStore 的 StorageLevel 
是 OFF_HEAP。 
ExternalBlockStore 中 是 如 何 存 取 block 的 呢 ? 仍然 以 putBytes 方法 为 例 ，ExternalBlock- 
Store 中 putBytes 方法 的 源 代码 如 下 所 示 。 


1. 
2 
3. 





override def putBytes( blockId :BlockId , bytes: ByteBuffer, level: StorageLevel) :PutResult = | 
putIntoExternalBlockStore( blockId , bytes ,returnValues = true ) 


| 





putBytes 方法 接受 3 个 参数 ， 分 别 是 Blockld 、ByteBuffer 和 StorageLevel， 这 3 个 参数 的 
含义 同 DiskStore 和 MemoryStore 的 putBytes 方法 的 参数 ， 分 别 代 表 Block 对 象 ，Block 对 应 的 
字 节 数组 和 存储 级 别 ， 这 里 StorageLevel 的 取 值 为 OFF_HEAP， 该 方法 返回 PutResult 对 象 。 
在 putBytes 方法 内 部 调用 putIntoExternalBlockStore 方法 ， 该 方法 用 于 将 Block 消息 存 人 Ex- 
eternalBlockStore 中 ， 其 源 代码 如 下 所 示 。 


. private def putIntoExternalBlockStore( 
blockld : Blockld, 
bytes: ByteBuffer, 
returnValues: Boolean) :PutResult = | 


1 

2 

3 

4 

Se logTrace( s" Attempting to put block $ blockId into ExternalBlockStore" ) 

6 // we should never hit here if externalBlock Manager is None. Handle it anyway for safety. 
7 

8 

9 








try | 
// 开 始 时 间 
val startTime = System. currentTimeMillis 
10. //externalBlockManager 是 否 被 定义 
11. if( externalBlock Manager. isDefined ) | 
12. // 调 用 duplicate 方法 得 到 bytes 的 只 读 副本 
13. val byteBuffer = bytes. duplicate( ) 
14. byteBuffer. rewind( ) 
15. // 调 用 externalBlockManager 的 putBytes 方法 ,将 byteBuffer 存 人 ExternalBlockStore 中 
16. externalBlockManager get. putBytes( blockId , byteBuffer) 
I // 得 到 byteBuffer 的 大 小 信息 
18. val size = bytes. limit( ) 
19. // 如 果 returnValues 为 true, 返 回 Right(bytes) ,否则 返回 null 
20. val data = if( returnValues) | 
2 Right( bytes) 


办 2 | else | 
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2 null 

24. | 

25. // 完 成 时 间 

26. val finishTime = System. currentTimeMillis 

2 了 // 返 回 PutResult 对 象 

28. PutResult( size ,data) 

29. | else | 

30. // 如 果 没 有 定义 externalBlockManager ,打印 错 误 日 志 

31. logError ( s" Error in putBytes ( $ blockId ) :no ExternalBlockManager has been con- 
figured" ) 

2 PutResult( ~—1,null,Seq( (blocklId, BlockStatus. empty) ) ) 

33. | 

34. wn 


将 Block 存放 到 JVM 外 部 存储 系统 中 必须 借助 ExternalBlock Manager, 首先 判断 Exter- 
nalBlock Manger 是 否定 义 . 如 果 没 有 定义 3 则 打印 出 ExternalBlockManger 没有 定义 的 信息 ; 
如 果 定 义 了 ExternalBlockManger， 调 用 externalBlockManger. get. putBytes 方法 将 byteBuffer 存 
入 外 部 系统 中 。 

这 里 提 到 了 ExternalBlockManager， 它 是 一 个 抽象 类 ,定义 了 使 用 外 部 存储 系统 存 取 
Block 的 方法 。 ExternalBlock Manager 的 源 代码 如 下 所 示 。 


























1. private[ spark | abstract class ExternalBlockManager | 
2. // 定 义 的 BlockManager 对 象 ,因为 BlockManager 是 和 其 他 模块 交互 的 类 ,其 中 有 一 些 有 用 的 
方法 ,可 以 在 ExternalBlockManager 中 使 用 ,如 dataDeserialize \blockManager. conf 对 象 等 











3 protected var blockManager: BlockManager = _ 

4. ”// 重 写 的 toString 方法 

5 override def toString: String = | " External Block Store" | 

6. // 初 始 化 方法 ,该 方法 传人 BlockManager 和 Executor 的 id 编号 
Z 

8 

9 





def init( block Manager: Block Manager, executorld :String) :Unit = | 
this. block Manager = block Manager 
> 

10. // 移 除 blockId 对 应 的 block 数据 

yl def removeBlock(blockId :BlockId ) : Boolean 

12. /检查 blockId 对 应 的 block 是 否 存在 

ls def blockExists( blockId: BlockId ) : Boolean 

14. ”// 加 入 block , 值 为 ByteBuffer 类 型 

15. def putBytes( blockId :BlockId ,bytes:ByteBuffer) :Unit 

16. /加 入 block , 值 为 可 和 欠 代 类 型 

17. def putValues(blockId:BlockId ,values:Iterator[ _] ) :Unit = | 

18. // 调 用 blockManager 的 dataSerialize 方法 ,将 可 迭代 的 values 数据 序列 化 成 ByteBuffer 
数据 

19. val bytes = block Manager. dataSerialize( blockId ,values ) 
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20. // 调 用 putBytes 方法 ,加 入 block 数据 

21. putBytes( blockId ,bytes ) 

22 1 

23. ”// 查 询 并 返回 blockId 对 应 的 block 数据 ,返回 类 型 为 Option[ ByteBuffer] 
24. def getBytes( blockId :BlockId) :Option[ ByteBuffer | 

25. ”// 查 询 并 返回 blockId 对 应 的 block 数据 ,返回 类 型 为 Option[ Iterator[ _]] 
26. def getValues(blockId:BlockId) :Optionl Iterator[ _]]=| 

网关 getBytes( blockId). map(buffer => blockManager. dataDeserialize(blockId ,buffer) ) 
29 0 

29. ”// 得 到 blockld 对 应 的 block 的 大 小 

30. def getSize( blockld: Blockld) :Long 

31. /关闭 ExternalBlockManager, 这 是 一 个 钧 子 方法 

32. def shutdown( ) 

230 








ExternalBlockManager 抽象 类 定义 了 使 用 外 部 系统 存储 Block 的 基本 的 抽象 方法 ， 由 具体 
存储 系统 实现 。 

ExternalBlockManager 中 的 init 方法 用 于 初始 化 ExternalBlockManager, 该 方法 有 两 个 参 
数 ， 第 一 个 参数 是 BlockManager， 第 二 个 参数 是 String 类 型 的 executorld，BlockManager 定义 
了 供 外 部 模块 调用 的 公共 接口 ，BlockManager 中 提供 了 数据 序列 化 和 反 序 列 化 的 方法 ,在 
ExternalBlockManager 中 可 以 使 用 以 下 几 个 方法 。 

e removeBlock ， 根 据 blockId 删除 对 应 的 Block。 

。 BlockExists ， 判 断 blockId 对 应 的 Block 在 外 部 存储 系统 中 是 否 存在 。 

e putBytes， 将 blockId 对 应 的 数据 存 入 外 部 存储 系统 。 

e putValues ， 将 blockId 对 应 的 数据 存 人 外 部 存储 系统 。 

e getBytes， 通 过 blockId， 取 出 对 应 的 Block。 

e getValues， 通 过 blockId， 取 出 对 应 的 Block 。 

e getSize， 返 回 blockId 对 应 的 Block 的 大 小 。 

shutdown 在 系统 关闭 时 被 调用 ， 用 于 清理 外 部 存储 系统 中 持久 化 了 的 数据 ， 例 如 ， 在 
TachyonBlockManager 中 ， 该 方法 用 于 递归 删除 某 些 保存 数据 的 目录 。 

目前 在 Spark 中 ，ExternalBlockManager 抽象 类 只 有 一 个 实现 ， 即 针对 Tachyon 的 实现 ， 
这 个 实现 类 是 org. apache. spark. storage. TachyonBlockManager， 接 下 来 看 一 下 TachyonBlock- 
Manager 中 重 写 的 相关 方法 。 

先 来 看 一 下 TachyonBlock Manager 中 init 方法 的 实现 源 代码 如 下 。 





























1. override def init( block Manager: Block Manager, executorld: String) :Unit = | 

2 super. init( block Manager , executorld ) 

3 // 得 到 Tachyon 中 设置 的 baseDir, 该 值 可 以 通过 spark. externalBlockStore. baseDir 配置 
4. val storeDir = blockManager. conf. get( ExternalBlockStore. BASE_DIR,"/tmp_spark_tachyon" ) 
5 
6. 
































// 得 到 保存 文件 夹 的 名 称 ,该 值 可 以 通过 spark. externalBlockStore. folderName 配置 
val appFolderName = block Manager. conf get( ExternalBlockStore. FOLD_NAME) 
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9 // 由 storeDir appFolderName 和 executorld 拼装 成 rootDirs 
8. rootDirs =s" $ storeDir/ $ appFolderName/ $ executorld" 
9. [获得 Tachyon 的 master 配置 , 默认 为 tachyon://localhost: 19998, 该 值 可 以 通过 
spark. externalBlockStore. url 进行 配置 
10. master = block Manager. conf. get( ExternalBlockStore. MASTER_URL," tachyon://localhost: 





19998" ) 
11. ”// 如 果 master 不 为 空 ,通过 TachyonFs 的 get 方法 ,由 master 地 址 得 到 TachyonFS 对 象 
[2 client =if(master! =null && master! ="")| 
3 TachyonFS. get( new TachyonURI( master) ,new TachyonConf( ) ) 
14. | else | 
15. // 若 master 为 空 ,返回 null 
16. null 


这 | 
18. [[ 若 client 为 null ,打印 错误 日 志 并 抛 出 IOException 异常 
19. if( client == null) | 





20. logError( " Failed to connect to the Tachyon as the master address is not configured" ) 
21. throw newIOException( " Failed to connect to the Tachyon as the master" + 

2 "address is not configured" ) 

238 | 





过 


到 条 // 得 到 每 一 个 Tachyon 目录 下 子 目 录 的 个 数 ,该 个 数 可 以 通过 spark. external Block- 





Tt 





Store. subDirectories 配 























25. subDirsPerTachyonDir = block Manager. conf. get( " spark. externalBlockStore. subDirectories" ， 























26. ExternalBlockStore. SUB_DIRS_PER_DIR ). toInt 
2 // 使 用 rootDirs 创建 根 目 录 ,并 在 根 目录 中 创建 子 目录 
28. tachyonDirs = createTachyonDirs( ) 


29. /创建 二 维 数组 
30. subDirs = Array. fill( tachyonDirs. length ) ( new Array[ TachyonFile | (subDirsPerTachyonDir) ) 
31. // 为 每 一 个 Tachyon 目录 注册 shutdown 回调 函数 , 当 发 生 shutdown 时 ,删除 目录 














3 tachyonDirs. foreach ( tachyonDir = > ShutdownHookManager. registerShutdownDeleteDir 


(tachyonDir) ) 
3 





init 方法 中 ， 通 过 传人 的 BlockManager 中 的 SparkConf 对 象 取出 外 部 存储 的 路 径 ， 该 路 
径 通 过 spark. externalBlockStore. baseDir 配置 ， 并 通过 SparkConf 对 象 取出 Tachyon 保存 数据 
文件 夹 的 名 称 ， 该 名 称 可 以 通过 spark. externalBlockStore. folderName 配置 。 使 用 storeDir 、ap- 
pFolderName 和 executorld 拼接 成 一 个 数据 块 存储 的 根 路 径 。 该 路 径 格 式 为 /storeDir/appFol- 
derName/executorId。 通 过 SparkConf 对 象 取出 Tachyon 的 配置 URL， 该 配置 项 可 以 通过 

















spark. externalBlockStore. url 来 配置 。 得 到 Tachyon 的 master 地 址 之 后 ， 通 过 TachyonFS. 
(new TachyonURI( master) ,new TachyonConf( ) ) 方法， 得 到 Tachyon 分 布 式 文件 系统 的 3 








get 


用 


TachyonFS， 通 过 该 client， 可 以 非常 方便 地 使 用 TachyonFS 进行 创建 、 删 除 和 存 取 数 据 操作 。 
init 方法 中 另外 一 个 重要 的 操作 是 创建 目录 首先 通过 spark. externalBlockStore. subDi- 
rectories 配置 项 获得 子 日 录 的 个 数 ， 上 默认 情况 下 为 64 个， 可 以 通过 spark. externalBlockStore. 
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subDirectories 配置 项 来 配置 。 第 28 行 调用 createTachyonDirs 方法 ， 使 用 拼凑 出 来 的 rootDirs 创 
建 目 录 。 创 建 好 目录 后 ， 使 用 subDirectories 参数 构建 一 个 二 维 数 组 ， 该 二 维 数组 有 tachyon- 
Dirs. length 行 ，subDirsPerTachyonDir 列 。 
init 方法 完成 Tachyon 目录 的 创建 准备 工作 ,那么 TachyonBlockManager 是 如 何 存 取 数据 > 
的 呢 ? 还 是 以 putBytes 方法 为 例 ，putBytes 的 源 代码 如 下 所 示 。 














1. override def putBytes( blockId :BlockId ,bytes:ByteBuffer) :Unit = | 
2 // 调 用 getFile 方法 ,使 用 哈 希 也 数 将 blockld 映射 到 一 个 文件 
3. val file = getFile( blockId ) 

4 // 得 到 文件 上 的 输出 流 

SE val os =file. getOutStream( WriteType. TRY_CACHE ) 
6 

% 

8 

9 








try | 
// 调 用 FileOutStream 上 的 write 方法 写 人 字 节 数据 
os. write( bytes. array( ) ) 





| catch | 
10. // 捕 获 异常 ,关闭 流 
11. case NonFatal(e) => 
1 logWarning( s" Failed to put bytes of block $ blockld into Tachyon" ,e) 
3% os. cancel( ) 
14. | finally | 
15. /关闭 流 
16. os. close( ) 
jy } 
18. | 





该 方法 传人 两 个 参数 ， 第 一 个 参数 是 BlockId 对 象 ， 该 对 象 中 包含 name 等 属性 及 方法 。 
第 二 个 参数 是 ByteBuffer 数组 ， 为 竺 存储 的 字 节 数据 。 上 面 源 代码 的 第 3 行 调 用 getFile 方 
法 ， 得 到 blockId 经 哈 希 映射 后 的 文件 ， 得 到 文件 对 象 ， 使 用 文件 上 的 输出 流 将 字 节 数据 写 
入 文件 中 。 
通过 TachyonBlockManager 查找 Block 信息 也 非常 简单 只 需 传 人 blockId 在 Tachyon 系 
统 中 找 出 对 应 的 数据 返回 即 可 。 这 里 以 getBytes 方法 为 例 ， 源 代码 如 下 。 

















1. override def getBytes( blockId: BlockId) :Option[ ByteBuffer] = | 

多 // 调 用 getFile 方法 ,使 用 blockId 中 的 name 属性 ,由 哈 希 函数 映射 得 到 文件 
3 val file = getFile(blockId ) 

4 // 如 果 fle 为 空 或 者 TachyonFile 的 locationHosts 大 小 为 0, 则 返回 None 
5. if(file == null | | file. getLocationHosts. size ==0) | 
6 

% 

8 

9 











return None 
| 
// 得 到 TachyonFile 上 的 输入 流 
val is =file. getInStream( ReadType. CACHE) 
10. try | 
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11. // 文 件 大 小 











能 调 优 


| val size = file. length 

13. // 创 建 length 长 度 的 字 节 数组 

14. val bs = new Array[ Byte | ( size. asInstanceOf[ Int | ) 

15. // 使 用 ByteStreams 的 readFully 方法 从 输入 流 读 取 数 据 到 bs 中 
16. ByteStreams. readFully(is ,bs) 

17. /返回 读 取 到 的 数据 

18. Some(ByteBuffer. wrap( bs) ) 

19. | catch | 

20. // 捕 获 异常 ,返回 None 

i case NonFatal(e) => 

2 logWarning( s" Failed to get bytes of block $ blockId from Tachyon" ,e) 
2 None 

24. | finally | 

2 // 关 闭 输 入 流 

26. is. close( ) 

2 } 

28. | 


在 getBytes 方法 中 ， 调 用 getFile 方法 ， 找 出 blockld 
过 文件 的 输入 流 ， 读 出 字 节 数据 并 返回 。 


经 哈 希 函数 映射 后 对 应 的 文件 ， 通 











至 此 ，DiskStore 、MemoryStore 和 ExternalBlockStore 都 已 讲解 完 。 在 Spark 中 拥有 不 同 的 
BlockStore 实现 ， 并 且 这 些 实现 有 可 能 继续 增加 ， 为 了 对 用 户 屏蔽 这 些 内 部 的 细节 ， 并 保证 





Spark 今后 对 不 同 存储 的 扩展 ，Spark Storage 模块 对 外 提供 








t 了 一 个 统一 的 方法 类 BlockManager。 





在 BlockManager 中 提供 了 存 取 数据 的 方法 ， 不 必 关 心 不 同 Store 的 具体 实现 细节 ， 只 需 通 过 








配置 使 用 不 同 的 StorageLevel，BlockManager 就 能 自动 选择 不 同 的 存储 ， 并 调用 该 存储 的 


方法 。 
4. 通过 BlockManager 读 写 数据 








既然 BlockManager 是 一 个 统一 的 接口 ， 那 么 在 BlockManager 中 肯定 提供 了 读 写 数据 的 
方法 ， 并 且 在 这 些 方法 中 会 根据 不 同 的 StorageLevel， 调 用 BlockStore 接口 实现 类 的 方法 来 读 
写 数据 。 接 下 来 看 一 下 BlockManager 提供 的 读 写 方法 ，BlockManager 提供 了 putBlockData 方 





法 ， 用 于 存储 数据 ， 该 方法 的 源 代码 如 下 。 





override def putBlockData(blockId :BlockId , data: ManagedBuffer, level: StorageLevel) :Unit = | 


1 
之 // 调 用 putBytes 方法 存放 数据 

全 putBytes(blockId , data. nioByteBuffer( ) ,level) 
te 








该 方法 有 3 个 参数 ， 第 一 个 参数 是 BlockId 对 象 ; 第 二 个 参数 是 ManagedBuffer， 表 示 待 
存 数据 ; 第 三 个 参数 是 StorageLevel， 用 于 指定 存储 的 级 别 。 方 法 中 调用 putBytes 方法 ， 该 方 





法 的 源 代 码 如 下 所 示 。 





1. 
之 
3 
4 
5 
6 
所 
8 
9 


10. 
11. 
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def putBytes( 


blockld : Blockld, 
bytes: ByteBuffer, 
level: StorageLevel, O) 
tell Master: Boolean = true， 
effectiveStorageLevel :Option| StorageLevel | = None) :Seq| ( BlockId ,BlockStatus) ] = | 

// 要 求 bytes 不 为 空 

require( bytes! =null," Bytes is null" ) 

// 调 用 doPut 方法 , 存 人 数据 

doPut( blockId ,ByteBufferValues(bytes) ,level,tellMaster ,effectiveStorageLevel) 
| 











在 putBytes 方法 中 ，tellMaster 参数 用 于 设置 在 存 人 数据 后 是 否 通知 master， 默 认为 true。 
还 有 一 个 参数 是 effectiveStorageLevel， 设 置 有 效 的 存储 级 别 ， 默 认为 None。require 用 于 检测 
传人 的 bytes 是 否 为 null， 如 果 为 空 将 以 “Bytes is null” 作 为 异常 消息 并 抛 出 TllegalArgumen- 
tException 异常 。putBytes 方法 主要 完成 将 一 个 序列 化 的 字 节 数组 存 和 人 BlockManager， 并 返回 
一 个 更 新 后 的 块 列表 。 该 方法 中 调用 了 doPut 方法 ， 源 代码 如 下 。 





1 
2 
3 
4 
3 
6 
% 
8 
9 


10. 
11. 
2 
13. 
14. 
15. 
16. 


17. 
18. 
让 中 
20. 
2 
2 














. private def doPut( 


blockld : Blockld, 

data: BlockValues, 

level: StorageLevel, 

tell Master: Boolean = true, 

effectiveStorageLevel :Option| StorageLevel | = None) 
:Seq[ (BlockId ,BlockStatus) ] = | 


. // 检 查 blockld 是 否 为 null , 若 为 null , 抛 出 人 egalArgumentException 异常 


require( blockId! =null," Blockld is null" ) 
//level 不 能 为 null ,并 且 level 合法 ,否则 抛 出 legalArgumentException 异常 
require(level! =null && level. isValid," StorageLevel is null or invalid" ) 
// 检 查 effectiveStorageLevel 
effectiveStorageLevel. foreach | level => 
require( level!l =null && level. isValid," Effective StorageLevel is null or invalid" ) 
| 
// 新 建 数组 ,该 数组 用 于 返回 数据 。 数 组 中 存放 用 BlockId 和 BlockStatus 组 成 的 二 维 
元 组 
val updatedBlocks = new ArrayBuffer[ (BlockId ,BlockStatus ) ] 
//put 操作 产生 的 Block J 
val putBlockInfo = | 
// 构 建 BlockInfo 对 象 tinfo 
val tinfo = new BlockInfo( level ,tellMaster) 
// 如 果 blockInfo 这 个 TimeStampedHashmap 中 没有 blockId , 则 加 入 此 BlockId 和 tinfo， 
putIfAbsent 方法 返回 key 对 应 的 更 新 此 key 的 value 之 前 的 value, 即 保留 老 的 信息 
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25 val oldBlockOpt = blockInfo. putIfAbsent( blockId ,tinfo ) 

24. // 如 果 oldBlockOpt 有 定义 ,说 明 blockInfo 这 个 TimeStampedHashmap 中 有 blockId 对 应 
的 信息 ,直接 返回 updatedBlocks ,此 时 updatedBlocks 为 一 个 ArrayBuffer 对 象 ,对 象 内 无 值 

2 if( oldBlockOpt. isDefined ) | 

26. if( oldBlockOpt. get. waitForReady( ) ) | 

2 logWarning( s" Block $ blockId already exists on this machine; not re ~ adding it" ) 

28. return updatedBlocks 

29. | 

30. oldBlockOpt. get 

31. | else | 

8 // 若 oldBlockOpt 没有 定义 ,返回 tinfo 对 象 

33. tinfo 

34. } 

35. } 

36. /开始 时 间 

3 val startTimeMs = System. currentTimeMillis 

38. var valuesAfterPut : Iterator[ Any | = null 


89 var bytesAfterPut: ByteBuffer = null 

40. var Size =0OL 

41. /进行 put 操作 的 有 效 的 StorageLevel 

42. val putLevel = effectiveStorageLevel. getOrElse( level) 

43. // 启 动 一 个 线程 ,在 本 地 存储 之 前 ,异步 初始 化 好 要 进行 见 余 备份 的 数据 。 这 有 助 于 提 
高 发 送 数 据 的 速度 ,从 而 提高 性 能 









































44. val replicationFuture = data match | 

45. case b: ByteBufferValues if putLevel. replication >1 => 

46. // 如 果 replication 设置 为 大 于 1, 则 通过 ByteBuffer 的 duplicate 方法 得 到 一 个 只 读 的 
副本 数据 

47. val bufferView = b. buffer. duplicate( ) 

48. Future | 

49. // 在 线程 池 中 执行 replicate 操作 ,这 是 一 个 阻塞 型 操作 ,该 操作 将 会 把 blockId 对 
应 的 bufferView 数据 复制 到 另 一 个 结 点 上 ,这 是 一 个 阻塞 型 操作 , 待 复制 完成 后 才 返 回 

50. replicate( blockId ,bufferView ,putLevel) 

51. | (futureExecutionContext) 

Ss case _ => null 

5 } 

54. /防止 其 他 线程 get 这 个 block ,使 用 该 putBlockInfo 上 的 同步 块 进行 同步 操作 ,直到 marked 
成 为 true 


55. putBlockInfo. synchronized | 
56. //marked 此 时 为 false 





本 7 var marked = false 
58. try | 
59. //returenValues 表示 是 否 返 回 put 操作 的 值 ,blockStore 表示 存储 方式 
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64. 
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val(returnValues ,blockStore :BlockStore) = | 
// 内 存 存储 ,返回 true 和 memoryStore 
if( putLevel. useMemory ) | 
// 首 先 将 数据 放 入 内 存 , 奉 在 useDisk 为 true 的 情况 下 内 存 不 能 满足 存储 ,将 会 OO 
把 此 block 溢出 到 磁盘 
(true ,memoryStore ) 
| 
//OFF_HEAP 存储 ,返回 false 和 externalBlockStore 
else if( putLevel. useOffHeap ) | 
(false ,externalBlockStore ) 
| 
// 人 磁盘 存储 ,diskStore 
else if( putLevel. useDisk ) | 
// Don t get back the bytes from put unless we replicate them 
(putLevel. replication > 1 , diskStore ) 
| else | 
// 若 没有 设置 StoreageLevel, 抛 出 BlockException 异常 
assert( putLevel == StorageLevel. NONE) 























throw newBlockException( 


blockId ,s" Attempted to put block $ blockld without specifying storage level!l" ) 


| 
// 匹配 put 操作 存 和 人 的 值 的 类 型 ,调用 blockStore 的 方法 
val result = data match | 
// 可 迭代 值 类 型 ,调用 blockStore 的 putlterator 方法 


case IteratorValues( iterator) => 




















blockStore. putlterator( blockId , iterator, putLevel ,returnValues) 
// 数 组 类 型 的 值 ,调用 blockStore 的 putArray 方法 


case ArrayValues( array) => 

















blockStore. putArray( blockId , array , putLevel ,returnValues ) 
//ByteBufferValues 类 型 的 值 ,调用 bleokStore 的 putBytes 方法 
case ByteBufferValues( bytes) => 
bytes. rewind( ) 
blockStore. putBytes( blockId ,bytes ,putLevel) 
| 
/获得 结果 大 小 
size = result. size 
// 对 结果 数据 类 型 进行 匹配 ,返回 put 操作 后 的 result 


result. data match | 








case Left( newlterator)if putLevel. useMemory => valuesAfterPut = newlterator 
case Right( newBytes) => bytesAfterPut = newBytes 


case _=> 
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101. | 

102. /7 如 果 使 用 内 存 存储 ,遍历 result 结果 中 的 droppedBlocks ,将 溢出 到 磁盘 的 block 添 
加 到 updatedBlocks 数组 中 

103. if( putLevel. useMemory ) | 

104. result. droppedBlocks. foreach | updatedBlocks +=_ 

105. } 

106. // 得 到 当前 block 的 状态 

107. val putBlockStatus = getCurrentBlockStatus ( blockId , putBlockInfo) 

108. // 判 断 状态 中 的 storageLevel 不 为 NONE 

109. if( putBlockStatus. storageLevel! = StorageLevel. NONE ) | 

110. // 将 marked 标志 设置 成 rue 

111. marked = true 

112. // 调 用 putBlockInfo 的 markReady 方法 ,标记 该 block 写 操作 完成 

113. putBlockInfo. markReady( size ) 

114. // 如 果 tellMaster 为 true, 调 用 reportBlockStatus 方法 ,报告 状态 

115. if( tellMaster) | 

116. reportBlockStatus( blockId ,putBlockInfo ,putBlockStatus ) 

117. | 

118. updatedBlocks += ( (blocklId ,putBlockStatus ) ) 

119. } 

120. | 

121. 

i // 如 果 replication 大 于 1 ,异步 开始 数据 的 复制 操作 

123: if( putLevel. replication >1)| 

124. data match | 

| 取款 case ByteBufferValues( bytes) => 

126. if(replicationFuture! = null)| 

27 // 启 动 replicationFuture 线程 

128. Await. ready(replicationFuture ,Duration. Inf) 

129. | 

130. replicate( blocklId , bytesAfterPut, putLevel) 

131. | 

132. } 

133. 


134. BlockManager. dispose( bytesAfterPut) 
135. /返回 updatedBlocks 

136. updatedBlocks 

18 ya 





BlockManager 中 的 doPut 是 一 个 很 复杂 的 方法 ， 下 面 将 逐一 讲解 该 方法 中 的 代码 。 该 方 
法 根据 StorageLevel 设置 的 值 将 block 存 人 对 应 的 BlockStore 中 ， 如 果 有 必要 将 会 产生 并 保存 
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在 该 方法 中 ， 首 先 检查 blockId 、storageLevel 和 effectiveStorageLevel 是 否 为 空 ， 如 果 为 空 
将 会 抛 出 lllegal AreumentsException 异常 并 返回 。 新 建 一 个 名 为 updatedBlocks 的 ArrayBuffer, 
该 缓存 数组 中 存放 一 个 二 维 元 组 ， 元 组 第 一 位 存放 BlockId 对 象 ， 第 二 位 存放 BlockStatus 对 
象 ， 该 updatedBlocks 数组 用 于 返回 更 新 后 的 blocks 信息 。putBlockInfo 代码 块 中 构建 Block- 
Info 对 象 ， 首 先 会 到 blockinfo 这 个 TimeStampedHashmap 类 型 的 map 中 查找 blockld 对 应 的 
BlockInfo 是 否 已 经 定义 ， 如 果 没 有 查 到 对 应 的 BlockInfo 对 象 ， 使 用 storageLevel 和 tellMaster 
构建 一 个 BlockInfo， 并 存 入 blockInfo 中 ,返回 构建 好 的 BlockInfo; 如 果 已 经 定义 了 该 Block- 
Info， 返 回 旧 的 BlockInfo。 

如 果 StorageLevel 中 配置 的 replication 数目 大 于 1， 这 种 情况 下 ， 将 在 futureExecutionCon- 
text 线程 池 中 启动 线程 ， 在 线程 中 进行 数据 的 备份 操作 。 

在 putBlockInfo 同步 代码 块 中 ,根据 不 同 的 StorageLevel， 判 断 使 用 不 同 的 BlockStore， 
并 判断 是 否 需 要 返回 值 。 得 到 blockStore 之 后 ， 判 断 data 的 组 织 方式 ， 调 用 blockStore 的 具 
体 存 储 方法 实际 存储 Block 数据 。 

如 果 tellMaster 为 tue， 将 调用 reportBlockStatus ( blockId , putBlockInfo, putBlockStatus ) 方 
法 ， 问 master 报告 Block 的 状态 。 最 后 根据 StorageLevel 中 的 replication 数目 产生 副本 。 

在 doPut 函数 中 ， 只 需 完 成 以 下 几 项 工作 。 

1) 为 Block 创建 BlockInfo， 存 储 block 的 相关 信息 。 

2) 为 blockInfo 加 锁 ， 使 其 他 线程 不 能 访问 。 

3) 根据 StorageLevel， 将 Block 存 到 Memory 或 Disk 或 ExternalBlockStore 中 。 

4) 解锁 blockInfo， 使 其 他 线程 可 访问 。 

5) 根据 StorageLevel 中 的 replication 判断 是 否 将 Block 制作 成 副本 存放 。 

接 下 来 了 解 一 下 在 BlockManager 中 是 如 何 获 取 数 据 的 ， 首 先 来 看 一 下 get 方法 ， 其 源 代 
码 如 下 所 示 。 







































































1. /该 方法 用 于 在 本 地 结 点 或 者 远程 结 点 上 返回 blockId 对 应 的 block 数据 
2. def get(blockId:BlockId) :Option[ BlockResult] = | 

9 // 首 先 调用 getLocal 方法 ,查找 本 地 是 否 存 在 blockld 对 应 的 block 数据 
4 val local = getLocal( blockId ) 

5 // 如 果 有 定义 ,方法 直接 返回 local 数据 
6. if( local. isDefined ) | 
有 

8 

9 


























logInfo( s" Found block $ blockId locally" ) 
return local 
: | 
10.  // 在 本 地 没有 定义 该 blcokld 的 情况 下 ,查询 远程 结 点 上 是 否 存 在 该 blockld 对 应 的 block 
数据 
ls val remote = getRemote( blockId ) 
12. // 若 远程 结 点 上 有 定义 该 blockId ,直接 返回 remote 
13. if( remote. isDefined ) | 
14. logInfo( s" Found block $ blockId remotely" ) 


IIS return remote 





© 
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16. | 

1 // 如 果 本 地 和 远程 结 点 上 都 没有 该 blockld 对 应 的 blcok ,返回 None 
18. None 

To 


get 方法 中 ,根据 blockId， 首 先 调用 getLocal 方法 ， 从 本 地 blockManager 中 获得 数据 。 如 
果 获 得 了 数据 则 返回 ;如果 没有 获取 到 数据 ， 调 用 getRemote 方法 ， 尝 试 在 其 他 远程 blockMan- 
ager 中 查找 数据 ， 如 果 找 到 则 返回 ， 没 有 找到 则 返回 None。Spark 中 ,任务 往往 是 根据 block 
所 在 位 置 进行 分 配 的 ， 大 部 分 情况 下 通过 getLocal 就 能 找到 blockId 对 应 的 数据 ， 但 是 在 资源 
有 限 的 情况 下 ， 任 务 调 度 器 可 能 将 任务 调度 到 与 Block 所 在 结 点 不 同 的 结 点 上 执行 ， 这 种 情况 
下 必须 通过 getRemote 方法 得 到 远程 Block 数据 。 先 来 看 一 下 getLocal 方法 ， 如 下 所 示 。 



































1. def getLocal(blockId:BlockId) :Option[ BlockResult| = | 

六 logDebug( s" Getting local block $ blockId" ) 

3. // 调 用 doGetLocal 方法 

4 doGetLocal( blockld ,asBlockResult = true ). asInstanceOf| Option[ BlockResult | ] 
> 


getLocal 方法 根据 传人 的 Blockld 通过 调用 doGetLocal 方法 取得 BlockId 对 应 的 Block。 
doGetLocal 方 法 的 源 代码 如 下 所 示 。 








1. private def doGetLocal( blockId :BlockId ,asBlockResult: Boolean) :Option[ Any] = | 

2 // 首 先 从 blockInfo 这 个 TimeStampedHashmap 中 查找 是 否 有 blockId 

3 val info = blockInfo. get(blockId). orNull 

4. /如果 有 ,说 明 本 地 查找 blockId 成 功 ,返回 blockId 对 应 的 数据 

Se if(info! =null)| 

6. // 避 免 多 线程 访问 该 block ,使 用 info 的 synchronized 同步 块 

7 info. synchronized | 

8. // 青 次 检查 blockInfo 中 是 否 存在 blockId ,因为 removeBlock 方法 可 能 会 将 该 blockld 
对 应 的 数据 移 除 , 这 里 是 双 保 险 

9. if( blockInfo. get(blockId). isEmpty ) | 

10. logWarning( s" Block $ blockId had been removed'" ) 

11. // 如 果 再 次 检查 发 现 没 有 了 blockId 对 应 的 数据 ,返回 None 

2 return None 

13. | 

14. 

15. // 如 果 在 info 这 个 block 上 有 其 他 线程 正在 进行 写 操作 , 则 等 待 ,直到 其 他 线程 操作 

完成 

16. if( | info. waitForReady( ) ) | 

17. // 如 果 等 待 失败 ,返回 None 

18. logWarning( s" Block $ blockId was marked as failure. ") 

19. return None 

20. | 
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val level = info. level 
// 若 使 用 的 是 MEMORY 存储 级 别 ,查找 MemoryStore 并 返回 数据 
if( level. useMemory) | 
logDebug( s" Getting block $ blockId from memory" ) O) 
val result =if(asBlockResult) | 
memoryStore. getValues ( blockld ) .map ( new BlockResult ( _,， 
DataReadMethod. Memory ,info. size) ) 
| else | 
memoryStore. getBytes( blockId ) 
| 
result match | 
case Some( values) => 
return result 
case None => 


logDebug( s" Block $ blockld not found in memory" ) 


| 
A/ 如果 使 用 的 是 OFF_HEAP 存储 级 别 ,查找 ExternalBlockStore 返回 数据 
if( level. useOffHeap) | 

logDebug( s" Getting block $ blockId from ExternalBlockStore" ) 

if( externalBlockStore. contains( blockId) ) | 

val result =if(asBlockResult) | 
externalBlockStore. getValues(blockId ) 
. map(newBlockResult(_,DataReadMethod. Memory ,info. size ) ) 


| else | 








externalBlockStore. getBytes( blockId ) 
| 
result match | 
case Some( values) => 
return result 
case None => 
logDebug( s" Block $ blockld not found in ExternalBlockStore" ) 


| 
// 如 果 使 用 的 是 DISK 存储 级 别 , 通 过 DiskStore 查找 并 返回 数据 
if( level. useDisk ) | 

logDebug( s" Getting block $ blockId from disk" ) 

val bytes: ByteBuffer = diskStore. getBytes( blockId ) match | 











case Some(b) =>b 
case None => 


throw newBlockException( 
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02. blockId,s" Block $ blockId not found on disk ,though it should be" ) 

63. } 

64. assert(0 == bytes. position( ) ) 

65. // 判 断 是 否 启 用 内 存 存储 

66. if( | level. useMemory) | 

67. // 若 不 能 存储 在 内 存 中 ,直接 返回 数据 即 可 

68. if(asBlockResult) | 

69. return Some ( newBlockResult ( dataDeserialize ( blockId, bytes ) ， 

DataReadMethod. Disk, 

70. info. size) ) 

71. | else | 

nn return Some( bytes) 

7 | 

74. | else | 

75. // 若 可 以 存 入 内 存 中 ,将 查 出 的 数据 放 入 内 存 , 这 样 下 次 再 查找 该 block 数据 
时 ,直接 从 内 存 中 获取 即 ,以 提高 速度 

76. if( | level. deserialized ||! asBlockResult) | 

/a memoryStore. putBytes( blockId , bytes. limit,( ) => | 

78. val copyForMemory = ByteBuffer. allocate( bytes. limit) 

79. // 如 果 内 存 不 能 放下 该 block 数据 ,将 会 发 生 00M, 因 此 将 该 操作 放 入 \( ) 
=> ByteBuffer 中 并 且 懒 加 载 

80. copyForMemory. put( bytes ) 

81. 上) 

82. bytes. rewind( ) 

83. } 

84. if( | asBlockResult) | 

85. return Some( bytes) 

86. | else | 

87. // 如 果 asBlockResult 为 true, 调 用 dataDeserialize 方法 ,将 bytes 数据 反 序列 化 
成 对 象 

88. val values = dataDeserialize( blockId ,bytes ) 

89. if( level. deserialized ) | 

90. // 在 返回 值 之 前 在 内 存 中 缓存 

91. val putResult = memoryStore. putlterator( 

92. blockld , values , level , returnValues = true , allowPersistToDisk = false ) 

93. putResult. data match | 

94. case Left(it) => 

95. return Some( newBlockResult( it, DataReadMethod. Disk ,info. size ) ) 

96. ease => 

97. throw new SparkException(" Memory store did not return an iterator!" ) 

98. | 


首先 
info 不 为 
险 ， 再 次 
他 线程 写 
所 有 
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99. | else | 

100. return Some( newBlockResult( values ,DataReadMethod. Disk ,info. size) ) 
101. } 

102. } OO 
103. } 

104. } 

105. | 

106. | 

107. // 返 回 None 

108. None 

109. | 

















从 blockInfo 哈 希 表 中 取出 blockId 对 应 的 BlockInfo。 如 果 为 Null， 返回 None; 如 果 
null， 获 取 info 的 synchronize 同步 块 ， 保 证 只 有 一 个 线程 操作 该 blockInfo。 为 了 保 
判断 哈 希 表 中 该 BlockInfo 是 否 被 removeBlock 方法 删除 。 如 果 该 BlockInfo 正在 被 其 
和 人 数据 ， 等 待 其 他 线程 退出 ， 如 果 等 竺 失败， 返回 None。 

检查 条 件 都 通过 了 之 后 ， 根据 StorageLevel 调用 对 应 BlockStore 的 方法 ， 查 找 block- 





















































Id 对 应 的 Block 数据 并 返回 。 如 果 判 断 StorageLevel 使 用 的 是 Memory， 则 调用 memoryStore 的 


getValues 




















或 getBytes 方法 查询 块 数据 并 返回 ; 如 果 判 断 StorageLevel 使 用 的 是 OFF_HEAP， 




















则 调用 externalBlockStore 的 getValues 或 getBytes 方法 查找 数据 并 返回 ;如 果 判 断 StorageLevel 





使 用 的 是 
查询 出 来 
从 而 加 快 : 





在 本 ] 
是 否 有 该 blockId 对 应 的 Block 数据 。 接 下 来 了 解 一 下 getRemote 方法 ， 源 代码 如 下 。 


























Disk ， 则 调用 diskStore 的 getBytes 方法 查询 并 返回 数据 。 如 果 配 置 了 useMemory， 
的 数据 将 根据 内 存 情况 存 人 MemoryStore 中 ， 以 便 再 次 查询 时 直接 从 内 存 中 查找 ， 
查找 速度 。 

出 没有 查询 到 blockId 对 应 的 Block 数据 时 ， 会 调用 getRemote 方法 查询 远程 结 点 上 























1. def getRemote(blockId:BlockId) :Option[ BlockResult] = | 

久 logDebug(s" Cetting remote block $ blockId" ) 

3. // 调 用 doGetRemote 方法 

4 doGetRemote( blockId ,asBlockResult = true ). asInstanceOf| Option[ BlockResult | ] 
> 

















getRemote 方法 将 通过 其 他 结 点 上 的 BlockManager 查询 block， 将 查询 的 结果 作为 Block- 
Result 实例 。 在 该 方法 中 调用 doGetRemote 方法 。 源 代码 如 下 。 











1. private defdoGetRemote( blockId :BlockId ,asBlockResult: Boolean) :Option[ Any] = | 

2 // 检 查 blockld 是 否 为 null 

了 require( blockId! =null," Blockld is null" ) 

4. // 调 用 BlockManagerMaster 的 getLocations 方法 ,获得 blockId 的 位 置 ,并 使 用 Random 的 
shuffle 方法 ,将 位 置 打 乱 , 这 样 不 至 于 每 一 次 都 到 同一 个 远程 结 点 取出 blockId 对 应 的 数据 


5 val locations = Random. shuffle( master. getLocations( blockId) ) 
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6 // 抓 取 失 败 的 次 数 ,初始 为 0 
起 var numFetchFailures =0 

8 // 遍 历 locations 

9 


for( loc <— locations ) | 


10. logDebug( s" Getting remote block $ blockId from $ loc") 
11. val data =try | 

2 // 调 用 blockTransferService 的 fetchBlockSync 方法 ,异步 抓 取 远 程 结 点 上 的 数据 
13. blockTransferService. fetchBlockSync( 

14. loc. host ,loc. port ,loc. executorld ,blockId. toString ). nioByteBuffer( ) 
15. | catch | 

16. // 异 常 处 理 

lg 

18. } 

19. /如 果 返 回 的 数据 不 为 null 

20. if(data! =null) | 

2 // 如 果 asBlockResult 为 true 

22: if(asBlockResult) | 

2 人 返回 数据 ,退出 循环 

24. return Some( newBlockResult( 

2 // 调 用 dataDeserialize 方法 反 序列 化 data 

26. dataDeserialize( blockId , data ) ， 

2 DataRead Method. Network, 

28. data. limit( ) ) ) 

29. | else | 

30. // 返 回 数据 ,退出 循环 

31. return Some( data) 

32 } 

33. } 

34. logDebug( s" The value of block $ blockld is null" ) 

5 } 

36. logDebug( s" Block $ blockld not found" ) 

9 None 

38. | 




















doGetRemote 方法 首先 会 检查 blockId 是 否 为 空 ， 如 果 为 空 ， 则 会 抛 出 以 “Blockld is 
null” 为 错误 信息 的 lllegal Areumentkxeception 异常 。 如 果 存 在 blockId， 调 用 BlockManager- 
Master 的 getLocations 方法 ， 返 回 存 有 该 blockld 的 BlockManagerld 信息 。 使 用 Random. shuffle 
方法 得 到 BlockManagerld 列表 ， 以 保证 请 求 的 负载 均衡 。 

在 for 循环 中 ， 使 用 blockTransferService 的 fetchBlockSync 方法 异步 抓 取 远 程 BlockManag- 
er 上 对 应 的 blockId 数据 ， 该 方法 可 能 会 失败 ， 失 败 后 将 打印 失败 信息 ， 并 转 至 下 一 次 循环 ， 
直到 找到 数据 并 返回 。 如 果 没 有 查找 到 blockId 对 应 的 数据 ， 则 返回 None。 
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Partition 与 Block 的 对 应 天 系 








至 此 ， 已 了 解 了 Spark Storage 模块 存储 层 的 架构 及 代码 实现 。 目 前 为 止 ， 也 许 读者 还 有 一 
个 疑问 ，RDD 中 的 partition 是 如 何 与 Storage 中 的 blockId 对 应 的 呢 ? 接 下 来 将 揭 开 这 个 谜 。 











在 RDD 中 ,计算 的 重要 方法 是 iterator， 该 方法 的 源 代码 如 下 。 





. final def iterator( split: Partition, context: TaskContext) : Iterator[ 了] = 


// 判 断 StorageLeve 不 为 NONE 
if( storageLevel! = StorageLevel NONE) | 
调用 cacheManager 的 getOrCompute 方法 计算 


| else | 


// 调 用 computeOrReadCheckpoint 方法 ,从 checkpoint 中 得 到 数据 


computeOrReadCheckpoint( split ,context ) 


| 
10. | 




















1 
3 
4 
3 SparkEnv. get. cacheManager. getOrCompute( this ,split , context , storageLevel ) 
6 
有 
8 
9 


iterator 方法 中 ， 首 先 判 断 StorageLevel 是 否 设 置 ， 如 果 没 有 设置 ， 说 明 在 DiskStore、 

















MemoryStore 和 ExternalBlockStore 中 没有 存储 该 RDD。 反 之 ， 如 果 设 置 了 StorageLevel， 即 
StorageLevel 不 等 于 StorageLevel. NONE ， 则 说 明 在 BlockStore 中 存 有 该 RDD。RDD 作为 Spark 
中 最 ee ke se 可 以 将 多 次 使 用 的 











RDD 缓存 起 来 ， 再 次 使 用 时 直接 从 缓存 中 获取 ， 而 不 再 重新 计算 ， 











高 整体 性 能 。cacheM- 


anager 就 是 一 个 RDD 缓存 的 管理 类 ， 在 其 getOrCompute 因数 中 ， > 到 Partition 和 blockId 


之 间 的 对 应 关系 。getOrCompnute 函数 的 源 代 码 如 下 所 示 。 


. def getOrCompute[ T]( 
rdd: RDD[ T], 
partition :Partition ， 


context :TaskContext ， 


//RDDBlockId 建立 RDD 与 block 之 间 的 联系 


1 

和 2 

3 

4 

Sa storageLevel :StorageLevel ) : Iterator[T] = | 
6 

W 

8 val key = RDDBlocklId( rdd. id , partition. index) 
9 


10. | 


代码 中 使 用 rdd. id 和 partition. index 构建 出 一 个 RDDBlockId 对 象 ， 在 构建 RDDBlockId 


对 象 的 过 程 中 ， 重 写 name 方法 ,该 方法 的 代码 如 下 所 示 。 





1. case class RDDBlockId( rddlId:Int, splitIndex: Int) extends BlockId | 
2. override def name:String = "rdd_" +rddld +"_" + splitIndex 
Se 
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如 上 面 代 码 所 示 ， 此 时 的 blockId 用 传 入 的 rddId 和 splitIndex 拼凑 而 成 ， 格 式 如 ”rdd”_ 
+rddId +”_”+ splitIndex 格式 。 调 用 blockManager 的 get 方法 取出 blockId 对 应 的 数据 。 如 果 
blockManager 的 get 方法 返回 None， 说 明 BlockManager 中 没有 这 个 block， 需 要 通过 计算 获 
取 ， 并 将 计算 得 到 的 block 数据 存 人 BlockManager 中 。block 的 计算 和 存储 是 阻塞 的 ， 其 他 
的 线程 需要 等 到 该 block 装载 结束 后 才能 操作 该 block。 

RDD 中 的 Transaction 操作 和 Action 操作 ， 虽 然 逻辑 上 是 在 Partition 上 进行 的 操作 ， 但 最 
终 还 是 转换 成 了 Block， 实 际 上 对 数据 的 存储 都 发 生 在 Block 上 。 

本 节 对 Storage 模块 的 通信 层 和 存储 层 进行 了 较为 全 面 的 讲解 ,包括 Storage 模块 通信 层 
的 通信 模式 ， 以 及 存储 层 中 不 同 的 存储 实现 。 并 且 讲 解 了 RDD 中 针对 partition 的 计算 最 终 
都 转化 成 对 Block 的 计算 ， 通 过 代码 跟踪 的 方式 解释 了 RDD 中 Partition 和 Block 之 间 的 关 
系 。 实 际 上 Partition 和 Block 是 等 价 的 ， 只 是 看 待 的 角度 不 同 。 

在 下 一 节 中 ， 将 对 比 不 同 Storage Level 的 性 能 ， 并 对 如 何 正确 选择 StorageLevel 等 级 进 
行 探讨 。 


不 同 Storage Level 对 比 


Spark Storage 模块 中 设置 了 不 同 的 存储 级 别 ， 不 同 的 存储 级 别 在 性 能 和 容错 性 上 各 有 优 
势 。 比 如 MemoryStore 在 访问 速度 上 更 快 ， 但 是 由 于 数据 都 存放 在 JVM 内 存 中 ,会 占用 大 量 
的 JVM Storage 内 存 ， 严 重 情况 下 可 能 会 出 现 OOM。DiskStore 在 访问 速度 上 没有 MemoryStore 
快 ， 因 为 其 需要 读 写 磁盘 ， 频 繁 的 IYO 操作 会 大 大 地 降低 系统 性 能 ， 但 是 DiskStore 能 够 存 
储 的 文件 的 大 小 比 MemoryStore 大 得 多 。ExternalBlockStore 采用 JVM 外 部 的 存储 系统 ，Exter- 
nalBlockStore 的 典型 运用 就 是 Tachyon 内 存 分 布 式 文 件 系统 。 

在 本 节 中 ， 将 对 比分 析 不 同 StorageLevel 在 性 能 方面 的 对 比 ， 以 及 StorageLevel 存储 级 别 
的 选择 。 首 先 看 一 下 内 存 级 别 的 存储 ，StorageLevel 在 内 存 存储 上 提供 了 4 个 选择 ,分 别 是 
MEMORY_ONLY、 MEMORY_ONLY_2、MEMORY_ONLY_SER 和 MEMORY_ONLY_SER_2。 
接 下 来 分 别 对 这 4 种 存储 级 别 进行 对 比 。 

MEMORY_ONLY， 从 名 称 上 就 可 以 知道 ， 只 启用 内 存 存储 并 且 在 内 存 中 只 保留 一 份 数 
据 。 这 种 模式 最 大 的 缺点 是 数据 以 对 象 的 形式 存储 在 内 存 中 ， 当 数据 量 过 大 时 容易 造成 
O00M; MEMORY_ONLY_2， 这 种 存储 级 别 将 数据 存放 在 内 存 中 ， 并 在 远程 结 点 上 存储 一 份 
数据 的 副本 ， 其 优点 是 当 本 地 结 点 数据 被 破坏 时 ， 远 程 结 点 还 有 一 个 宛 余 的 备份 ， 增 加 了 抵 
抗 风险 的 能 力 。 缺 点 是 数据 仍然 以 对 象形 式 存 放 在 内 存 中 ,大 量 的 对 象 容易 导致 OOM， 并 
且 在 远程 结 点 元 余 备 份 ， 增 加 了 网 络 开销 ;MEMORY_ONLY_SER， 这 种 存储 模式 将 数据 序 
列 化 之 后 以 字 节 数组 形式 存放 在 内 存 中 ， 大 大 降低 了 内 存 的 消耗 ， 但 是 当 数据 量 超出 JVM 
分 配 的 内 存 空 间 时 ， 仍 然 会 出 现 0O0OM; MEMORY_ONLY_SER_2， 这 种 存储 模式 在 序列 化 数 
据 的 同时 ， 在 远程 结 点 宛 余 备 份 数据 ， 增 强 了 抵抗 风险 的 能 力 ， 数 据 量 过 大 也 会 出 现 OOM，， 
并 且 宛 余 备 份 还 增加 了 网 络 开销 。 

现在 的 集群 ， 虽 然 内 存 都 已 经 很 大 了 ， 但 是 即便 再 大 的 内 存 ， 也 不 能 保证 一 定 不 会 出 现 
OO0M。 万 事 都 有 利 有 次 ， 内 存 存储 在 速度 上 的 确 非 常 快 ， 但 跟 磁 盘 比 起 来 ， 其 容量 仍然 有 
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限 ， 在 期 盼 物理 内 存在 将 来 越 来 越 大 的 同时 ， 也 需要 采取 其 他 的 补救 措施 。 接 下 来 看 一 下 磁 
盘存 储 。 

StorageLevel 中 以 DISK_ONLY 代表 选择 磁盘 存储 ， 计 算 的 数据 将 通过 IZO 操作 存储 到 磁 
盘 上 ， 磁 盘 相 对 于 内 存 ， 其 优点 是 有 相对 充分 的 空间 对 数据 进行 存储 ， 当 然 其 缺点 是 访问 速 人 
度 慢 。DISK_ONLY_2 表示 使 用 磁盘 存储 ， 并 在 远程 结 点 上 进行 元 余 备 份 ， 增 加 了 抵抗 风险 
的 能 力 。 纯 的 MEMORY 和 纯 的 DISK 存储 都 有 其 优 缺 点 ， 能 不 能 取 两 者 的 长 补 两 者 的 短 呢 ? 
答案 当然 是 可 以 ， 只 需 同 时 使 用 内 存 和 磁盘 存储 即 可 ， 内 存 提供 高 速 的 访问 速度 ， 磁 盘 提 供 
相对 充分 的 存储 空间 。 

在 StorageLevel 中 ， 内 存 和 磁盘 有 4 种 不 同 的 组 合 方式 ， 分 别 是 MEMORY_AND_DISK、 
MEMORY_AND_DISK 2、MEMORY_AND_DISK_SER 和 MEMORY_AND_DISK_SER。MEMO- 
RY_AND_DISK 这 种 存储 方式 表示 ， 首 先 将 数据 放 在 内 存 ， 当 内 存 不 能 放下 该 block 数据 时 ， 
将 其 溢出 到 磁盘 中 ; MEMORY_AND_DISK_2 表示 在 本 地 和 远程 结 点 上 分 别 保存 ; MEMORY 
_AND_DISK_SER 表示 序列 化 存储 到 内 存 ， 当 内 存 不 足 时 ， 洲 出 到 磁盘 ;MEMORY_AND_ 
DISK_SER_2 在 MEMORY_AND_DISK 基础 上 增加 了 远程 结 点 的 宛 余 备份 。 

虽然 磁盘 和 内 存 存储 级 别 都 可 以 单独 提供 存储 服务 ， 但 其 各 有 优 缺 点 ， 磁 盘 和 内 存 的 配 
合 使 用 克服 了 单独 使 用 磁盘 和 内 存 存 储 的 缺点 。 有 没有 第 三 方 专门 提供 存储 服务 呢 ? 肯定 
有 ， 那 就 是 OFF_HEAP，OFF_HEAP 表示 堆 外 存储 ， 数 据 存储 在 JVM 外 边 ， 其 优点 是 让 第 
三 方 服务 专门 管理 数据 ， 而 JVM 中 只 负责 计算 ， 将 存储 和 计算 模块 分 离 ，JVM 中 少 了 存储 ， 
这 就 减少 了 JVM 进行 GC 的 可 能 ，JVM GC 是 相当 费时 的 操作 。Tachyon 提供 堆 外 存储 服务 ， 
Spark 中 目前 默认 使 用 的 堆 外 存储 是 Tachyon。 
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CP” Executor 内 存 模型 








Spark 实际 上 是 运行 于 多 JVM 之 上 的 分 布 式 计算 框 
架 ,， 各 个 JVM 通过 RPC 框架 通信 。 既 然 是 JVM， 那 
JVM 的 堆栈 空间 大 小 就 可 以 通过 参数 配置 。Spark Execu- 
tor 中 默认 JVM 堆 大 小 是 1 GB。 在 每 一 个 JVM 中 ， 需 要 2 
分 配 空间 用 于 缓存 数据 ， 还 需要 分 配 一 定 空间 用 于 计算 ， spark.memory.storageFraction 
对 于 JVM 的 运行 还 需要 预 留 部 分 空间 。 那 么 Spark 中 怎 
样 管理 JVM 中 内 存 分 配 的 呢 ? 

实际 上 Spark 在 JVM 内 存 管理 上 建 有 一 套 模型 。 该 ‖ os aa simipasii 1340 
模型 图 6-4 所 不 ‘ spark.memory.fraction 

从 图 中 可 以 看 到 ，Spark 启动 的 Executor 默认 的 堆 大 
小 是 1GB， 当 然 这 个 默认 堆 大 小 可 以 通过 spark.executor. 
mem 来 了 时 en 

为 了 安全 考虑 同时 避免 00M，Spark JVM 中 允许 使 
用 的 内 存 空间 占 JVM 堆 空 间 的 75% ,该 比例 可 以 通过 图 6-4 Executor JVM 内 存 模型 
spark. memory. fraction 来 配置 。 例 如 通过 spark. executor. 
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memory 配置 JVM 内 存 大 小 为 1024 MB ， 那 么 安全 的 阔 值 就 是 1024 * 0.75 MB。 

spark 作为 一 个 内 存 计算 框架 ， 可 以 在 内 存 中 缓存 数据 。Spark 通过 LRU 算法 将 数据 组 
存 到 内 存 中 ,这样 Spark JVM 中 就 有 大 量 的 内 存 被 用 来 缓存 数据 。 在 Spark 中 用 于 缓存 数据 
的 内 存 大 小 是 有 限制 的 。 该 值 默认 占 Executor And Storage 堆 空 间 的 50% ， 可 以 通过 
spark. memory. storageFraction 配置 该 比例 。 按 照 默 认 值 为 50% ， 则 用 于 缓存 数据 的 空间 大 小 
为 1024 * 0.75*0.5MB。 如 果 该 值 设置 得 过 大 ， 那 么 计算 内 存 占 的 比例 就 会 变 少 ， 这 将 可 
能 使 任务 更 加 频繁 的 溢出 到 磁盘 。 

Executor 内 存 的 大 小 ， 和 性 能 本 身 当 然 并 没有 直接 的 关系 ， 但 是 几乎 所 有 运行 时 性 能 相 
关 的 内 容 都 或 多 或 少 间 接 和 内 存 大 小 相关 。 这 个 参数 最 终 会 被 设置 到 Executor 的 JVM 的 
heap 尺寸 上 ， 对 应 的 就 是 Xmx 和 Xms 的 值 。 

理论 上 Executor 内 存 当 然 是 多 多 益 善 ， 但 是 实际 受 机 带 配 置 ， 以 及 运行 环境 ， 资 源 共 
享 ，JVM GC 效率 等 因素 的 影响 ， 还 是 有 可 能 需要 为 它 设 置 一 个 合理 的 大 小 。 多 大 算 合 理 ， 
要 看 实际 情况 。 

Executor 的 内 存 基本 上 是 Executor 内 部 所 有 任务 共享 的 ， 而 每 个 Executor 上 可 以 支持 的 
任务 的 数量 取决 于 Executor 所 管理 的 CPU Core 资源 的 多 少 ， 因此 你 需要 了 解 每 个 任务 的 数 
据 规 模 的 大 小 ， 从 而 推算 出 每 个 Executor 大 致 需要 多 少 内 存 即 可 满足 基本 的 需求 。 

如 何 知道 每 个 任务 所 需 内 存 的 大 小 呢 ? 很 难 统一 的 衡量 ， 因 为 除了 数据 集 本 身 的 开销 ， 
还 包括 算法 所 需 各 种 临时 内 存 空间 的 使 用 ， 而 根据 具体 的 代码 算法 等 不 同 ， 临 时 内 存 空间 的 
开销 也 不 同 。 但 是 数据 集 本 身 的 大 小 ， 对 最 终 所 需 内 存 的 大 小 还 是 有 一 定 的 参考 意义 的 。 
通常 来 说 每 个 分 区 的 数据 集 在 内 存 中 的 大 小 ， 可 能 是 其 在 磁盘 上 源 数据 大 小 的 若干 们 
(不 考虑 源 数据 压缩 ，Java 对 象 相 对 于 原始 数据 也 还 要 算 上 用 于 管理 数据 的 数据 结构 的 额外 
开销 )， 需 要 准确 的 知道 大 小 的 话 ， 可 以 将 RDD cache 在 内 存 中 ， 从 BlockManager 的 Log 输 
出 可 以 看 到 每 个 Cache 分 区 的 大 小 (其 实 也 是 估算 出 来 的 ， 并 不 完全 准确 ) 反 过 来 说 ， 如 果 
你 的 Executor 的 数量 和 内 存 大 小 受 机 器 物理 配置 影响 相对 固定 ， 那 么 你 就 需要 合理 规划 每 个 
分 区 任务 的 数据 规模 ， 例 如 采用 更 多 的 分 区 ， 用 增加 任务 数量 (进而 需要 更 多 的 批 次 来 运 
算 所 有 的 任务 ) 的 方式 来 减 小 每 个 任务 所 需 处 理 的 数据 大 小 。 

如 前 面 所 说 spark. executor. memory 决定 了 每 个 Executor 可 用 内 存 的 大 小 ， 而 spark. memo- 
ry. storageFraction 则 决定 了 在 这 部 分 内 存 中 有 多 少 可 以 用 于 Memory Store 管理 RDD Cache 数 
据 ， 剩 下 的 内 存 用 来 保证 任务 运行 时 各 种 其 他 内 存 空间 的 需要 。 

spark. memory. storageFraction 默认 值 为 0.5， 官 方 文 档 建议 这 个 比值 不 要 超过 JVM 0ld 
Gen 区 域 的 比值 。 这 也 很 容易 理解 ， 因 为 RDD Cache 数据 通常 都 是 长 期 驻 留 内 存 的 ， 理 论 上 
也 就 是 说 最 终 会 被 转移 到 0ld Gen 区 域 ( 如果 该 RDD 还 没有 被 删除 的 话 ) ， 如 果 这 部 分 数据 
允许 的 尺寸 太 大 ， 势 必 把 01d Gen 区 域 占 满 ， 造 成 频繁 的 FULL GC。 

如 何 调 整 这 个 比值 ， 取 决 于 你 的 应 用 对 数据 的 使 用 模式 和 数据 的 规模 ， 粗 略 的 来 说 ， 如 
果 频 繁 发 生 Full GC， 可 以 考虑 降低 这 个 比值 ， 这 样 RDD Cache 可 用 的 内 存 空间 减少 ( 剩 下 
的 部 分 Cache 数据 就 需要 通过 Disk Store 写 到 磁盘 上 了 )， 会 带 来 一 定 的 性 能 损失 ,但 是 腾 出 
更 多 的 内 存 空 间 用 于 执行 任务 ,减少 Full GC 发 生 的 次 数 ， 反 而 可 能 改善 程序 运行 的 整体 
性 能 。 
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Tachyon 


在 前 面 章 节 中 ， 讲 解 了 BlockStore 的 几 种 不 同 实现 ， 其 中 ExternalBlockStore 用 于 将 
BlockManager 中 的 Block 保存 到 外 部 存储 中 。Spark 中 默认 使 用 的 外 部 存储 系统 是 Tachyon， 
在 ExternalBlockStore 中 ， 将 会 调用 TachyonBlockManager 中 的 相关 方法 ， 对 Tachyon 中 的 数据 
进行 存 取 操作 。 在 本 节 中 ， 将 介绍 Tachyon 在 Spark 中 的 使 用 及 相关 的 API。 


区 了 加 Tachyon 简介 | 


Tachyon ( 意 为 超 光 速 粒子 ) 是 以 内 存 为 中 心 的 分 布 式 文件 系统 (2016 年 2 月 更 名 为 
Alluxio) ， 拥 有 高 性 能 和 容错 能 力 ， 能 够 为 集群 框架 (如 Spark 、MapReduce 等 ) 提供 可 靠 的 
内 存 级 速度 的 文件 共享 服务 。 从 软件 栈 的 层次 来 看 ，Tachyon 是 位 于 现 有 大 数据 计算 框架 和 
大 数据 存储 系统 之 间 的 独立 的 一 层 。 它 利用 底层 文件 系统 作为 备份 ， 对 于 上 层 应 用 来 说 ， 
Tachyon 就 是 一 个 分 布 式 文件 系统 。 

Tachyon 诞生 于 UC Berkeley 的 AMPLab ， 其 最 初出 现 是 为 了 解决 如 下 问题 。 

e 大 数据 分 析 流水 线 中 ， 数 据 共享 通过 基于 磁盘 文件 系统 (HDFS 等 ) 性 能 比较 缓慢 。 

e 大 数据 计算 引擎 的 处 理 进程 (如 Spark 的 Executor，MapReduce 的 Child JVM 等 ) 朋 演 

出 错 后， 缓存 的 数据 也 会 全 部 丢失 。 
e 基于 内 存 的 系统 存储 数据 宛 余 ， 对 象 太 多 会 导致 Java GC 时 间 过 长 。 
Tachyon 在 大 数据 分 析 软 件 栈 (Berkeley Data Analytics Stack) 中 的 所 属 层次 如 图 6-5 


所 示 。 
Spark k 
Ee 2 
i Hadoop 
Spark 计 算 框架 


Tachyon 分 布 式 内 存 文件 系统 























HDFS、S3 和 GlusterFS 等 分 布 式 磁盘 文件 系统 


Mesos 或 Yarn 或 其 他 集群 资源 管理 调度 框架 








图 6-5 Tachyon 在 大 数据 软件 栈 中 的 地 位 
从 图 6-5 中 可 见 ，Tachyon 是 架构 在 最 底层 的 分 布 式 文件 存储 和 上 层 的 各 种 计算 框架 之 


间 的 一 种 中 间 件 ， 主 要 职责 是 将 那些 不 需要 落地 到 磁盘 里 的 文件 落地 到 分 布 式 内 存 文件 系统 
中 ， 以 共享 内 存 ， 从 而 提高 效率 。 同 时 可 以 减少 内 存 宛 余 、GC 时 间 等 。 












内 核 机 制 解析 及 性 能 调 优 


Tachyon 的 架构 是 传统 的 Master 一 Slave 架构 ， 为 了 防止 单 点 故障 ， 可 以 使 用 Zookeeper 
做 HA。Tachyon 中 使 用 RamDisk (内 存 磁 盘 ) 技术 来 提高 对 文件 的 访问 速度 ，Tachyon 中 
Master 和 Worker 直接 的 通信 协议 是 Thrift。 

Tachyon 技术 在 业界 引起 了 广泛 的 关注 ， 其 开源 社区 也 越 来 越 活跃 。 在 本 节 中 ， 将 以 Tach- 
yon 最 新 版 本 0. 8. 2 来 讲解 ， 因 为 在 Spark 1. 6. * 中 ，Tachyon 采用 的 就 是 0. 8. 2 版 本 。 

















Tachyon API 的 使 用 习 


要 使 用 Tachyon 内 存 文 件 系统 ， 首 先 要 使 用 TachyonFileSystemFactory 得 到 一 个 Tachyon 
的 操作 客户 端 ， 通 过 客户 端 进行 文件 的 读 写 操作 。 得 到 Client 客户 端的 代码 如 下 。 





TachyonFileSystem tfs = TachyonFileSystemFactory. get( ) ; 





通过 TachyonFileSystemFactory 的 get 方法 ， 返 回 一 个 TachyonFileSystem 对 象 ， 通 过 该 对 
象 ， 对 文件 进行 存储 操作 。 接 下 来 讲解 Tachyon 中 对 文件 的 存 取 操 作 。 

1. 创建 文件 
通过 TachyonFileSystemFactory 对 象 创建 文件 也 是 十 分 简单 ， 就 跟 磁 盘 文 件 一 样 。 首 先 通 
过 TachyonURI 创建 一 个 Tachyon 文件 路 径 ， 并 使 用 文件 的 输出 流向 文件 写 入 数据 。 代 码 
如 下 。 








// 得 到 TachyonFileSyste 

TachyonFileSystem tfs = TachyonFileSystemFactory. get( ) ; 
// 新 建 TachyonURI 路 径 

TachyonURI path = new TachyonURI(" /myFile" ) ; 

// 根 据 TachyonURI 创建 文件 并 得 到 文件 的 输出 流 
FileOutStream out = tfs. getOutStream( path ) ; 
// 写 入 数据 

out. write( " hello tachyon!" ); 

// 关 闭 文 件 系 统 


10. out. close( ); 
2. 指定 非 默 认 值 


在 Tachyon 所 有 的 操作 中 ， 都 有 一 个 额外 的 选项 可 以 用 ， 它 允许 用 户 指 定 非 默认 的 设 
置 。 比 如 可 以 通过 这 个 选项 设置 非 默 认 的 数据 块 大 小 。 代 码 如 下 。 














Sr A el er 








// 得 到 TachyonFileSystem 

TachyonFileSystem tfs = TachyonFileSystemFactory. get( ); 

// 创 建 TachyonURI 

TachyonURI path = new TachyonURI("/myFile" ) ; 

// 通 过 OutStreamOptions 设置 块 大 小 为 128 MB 

OutStreamOptions options = new OutStreamOptions. Builder( ClientContext. getConf( ) ). setBlock- 
Size(128 * Constants. MB ). build( ) ; 

7. FileOutStream out = tfs. getOutputStream( path ,options ) ; 


SA SA a oe 
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3. LO 选项 

Tachyon 中 使 用 了 两 种 不 同 的 存储 类 型 ， Tachyon 管理 的 存储 和 底层 存储 。Tachyon 管理 
的 存储 是 分 配给 Tachyon Workers 的 内 存 、SSD 和 HDD， 而 底层 存储 是 指 被 S3 、HDFS 和 
Swift 等 管理 的 存储 资源 。 用 户 可 以 通过 TachyonStorageType 和 UnderStorageType 两 个 配置 选 O) 
项 指定 Tachyon 本 地 存储 和 底层 存储 的 合作 方式 。 表 6-1 所 示 是 TachyonStorageType 和 Un- 
derStorageType 不 同 的 组 合 方式 。 


表 6-1 TachyonStorageType 和 UnderStorageType 不 同 组 合 方式 







































































TachyonStorageType | UnderStorageType 组 合 结 果 读 数 据 写 数据 
MUST_CACHE, 读 取 数据 并 移 到 置换 的 最 高 层 ,| 数据 被 同步 写 人 Tach- 
NO_PERSIST 
PROMOTE 一 CACHE_PROMOTE | 并 在 Tachyon Worker 中 创 建 副本 yon Worker 
ee 数据 被 同步 写 人 Tach- 
CACHE_THROUGH, 读 取 数据 并 移 到 置换 的 最 高 层 ， 2 
PROMOTE | SYNCPERSISY | CACHE_PROMOTE | 并 在 Tachyon Worker 中 创建 副本 系统 Be a 
LL 
本 数据 被 同步 写 人 Tach- 
MUST_CACHE， | 对 于 每 一 个 完整 的 数据 块 ， 在 | 数据 被 同步 号 人 Tae- 
STORE NO_PERSIST i Tachyon Worker 中 创建 副本 yon worker， 不 写 人 底层 
ac nyon orker 田 存 py、 > 
任 储 系统 
es 数据 被 同步 写 入 Tach- 
STORE SYNC_PERSIST | ACHETHROUGH, | x 了 于 每 一 个 完整 的 数据 块 ， 在 的 让 存储 
” ~ CACHE Tachyon Worker 中 创建 副本 系统 
从 赤 
THROUGH, 先 从 Tachon 读 取 ， 如 果 没 有 再 | 数据 被 同步 写 人 底层 
NO_STORE SYNC_PERSIST i ee 2 
SO es NO_CACHE ”| 从 底层 存储 系统 读 ， 不 创建 副本 | 存储 系统 

















TachyonStorageType 和 UnderStorageType 的 不 同 组 合 ， 将 产生 出 不 同 的 读 、 写 数据 策略 。 

4. 打开 TachyonFile 

在 创建 好 Tachyon 文件 的 前 提 下 ， 可 用 通过 open 方法 打开 该 Tachyon 文件 。open 方法 返 
回 创建 好 的 TachyonFile 的 引用 。 代 码 如 下 。 


// 得 到 TachyonFileSystem 对 象 

TachyonFileSystem tfs = TachyonFileSystemFactory. get( ) ; 
// 确 保 /myFile 在 Tachyon 中 存在 

TachyonURI path = new TachyonURI( "/myFile" ) ; 

// 打 开 Tachyon 文件 

TachyonFile file = tfs. open( path ) ; 





GA 


5. 读 取 数 据 
Open 方法 打开 Tachyon 文件 操作 其 实 只 返回 一 个 TachyonFile 的 引用 ， 要 想得到 文件 中 的 
内 容 ， 还 需要 得 到 该 文件 上 的 输入 流 ， 通 过 输入 流 读 取 TachyonFile 文件 中 的 内 容 。 代 码 如 下 。 


TachyonFileSystem tfs = TachyonFileSystemFactory. get( ) ; 
TachyonURI path = new TachyonURI( "/myFile" ) ; 
TachyonFile file = tfs. open(path ) ; 


// 打 开 文件 ,获得 文件 的 输入 流 


ee 
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FileInStream in = tfs. getInStream( file ) ; 
// 读 取 数 据 

in. read(...); 

// 关 闭 文件 ,释放 锁 


in. close( ) ; 


更 多 API 的 使 用 ， 请 查看 Tachyon (Alluxio) 官方 网 站 :http://www. alluxio. org。 在 了 








解 了 Tachyon 基本 的 API 使 用 之 后 ， 下 面 介绍 Tachyon 在 Spark 中 的 应 用 。 





Tachyon 在 Spark 中 的 使 用 ) 





在 上 一 小 节 中 ,讲解 了 BlockStore 的 实现 之 一 ExternalBlockStore， 在 ExternalBlockStore 
中 通过 使 用 ExternalBlockManager 来 操作 Spark 内 存 中 的 数据 ， 可 以 看 到 ExternalBlock Manag- 
er 是 一 个 抽象 类 ,目前 该 类 的 唯一 实现 是 TachyonBlockManager， 包 路 径 是 org. apache. 
spark. storage. TachyonBlockManager。 在 TachyonBlockManager 中 ， 提 供 了 对 Tachyon 进行 存 取 
数据 操作 的 接口 。 

在 TachyonBlockManager 的 init 方法 中 ,通过 传人 的 blockManager 和 executorld， 找 到 
Tachyon 的 master 地 址 和 存放 文件 的 根 路 径 。 并 且 通 过 TachyonFS. get( new TachyonURI( mas- 
ter) ,new TachyonConf( ) ) 的 方法 调用 ， 返 回 一 个 TachyonFs 文件 系统 句柄 ， 通 过 该 文件 系统 
句柄 就 可 以 方便 地 存 取 文 件 了 。 值 得 注意 的 是 ， 在 Tachyon 0. 8. 2 中 TachyonFs 类 已 经 过 时 ， 
要 得 到 Tachyon 文件 系统 的 引用 ， 需 要 使 用 TachyonFileSystem. get 方法 。 

下 面 分 别 查 看 TachyonBlock Manager 中 的 源 代码 ， 了 解 Spark 中 是 如 何 使 用 Tachyon 进行 
数据 读 写 的 。 

1. TachyonBlockManager 向 Tachyon 中 存放 数据 

Spark 中 的 数据 要 存 人 Tachyon ， 需要 通过 TachyonBlockManager 提供 的 方法 ， 这 里 以 
putBytes 方法 为 例 ， 讲 解 Spark 中 是 如 何 使 用 Tachyon 存放 数据 的 。putBytes 方法 存放 Blockld 
对 应 的 字 节 数组 中 的 数据 ，putBytes 方法 的 源 代码 如 下 。 








a 
2 


3 
4 
5 
6. 
8 
9 






































override def putBytes( blockId :BlockId ,bytes:ByteBuffer) :Unit = | 
// 调 用 getFile 方法 ,以 blockId 中 的 name 属性 作为 哈 希 函数 的 参数 ,映射 得 到 Tachyon 对 
应 的 TachyonFile 
val file = getFile( blockId ) 
/打开 文件 上 的 输入 流 
val os =file. getOutStream( WriteType. TRY_CACHE ) 








by | 
// 向 输入 流 中 写 人 字 节 数组 数据 
os. write( bytes. array( ) ) 
| catch | 
/捕获 异常 
case NonFatal(e) => 
logWarning( s" Failed to put bytes of block $ blockld into Tachyon" ,e) 


avan 
中 

13. /关闭 输入 流 

14. os. cancel( ) 

15. | finally | 

16. // 关 闭 输 入 流 

17. os. close( ) 

18. | 

19. | 
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putBytes 方法 接受 两 个 参数 ,分别 是 BlockId 对 象 和 ByteBuffer 对 象 ， 分 别 代 表 RDD 产 


生 的 blockId 和 RDD 中 的 数据 。 通 过 getFile 





(blockId) 方法 ， 取 出 blockId 哈 希 映射 对 应 的 


TachyonFile ， 首 先 得 到 文件 上 的 输出 流 ， 再 将 byteBuffer 数据 写 和 人 TachyonFile 文件 中 。 也 许 
读者 会 感到 奇怪 ， 这 里 并 没有 对 Tachyon 的 操作 。 在 putBytes 方法 中 没有 看 到 任何 Tachyon 
相关 API 的 调用 ， 答 案 在 调用 的 getFile 方法 中 。getFile 的 源 代 码 如 下 。 


1. //getFile 方法 ,传人 Blockld 对 象 


2. def getFile( blockId:BlockId ) :TachyonFile = getFile( blockId. name) 





3. //getFile 方法 ,传人 BlockId 对 象 中 的 name 属性 





4. def getFile( filename:String) :TachyonFile = | 


// 计 算 fename 的 非 负 哈 硕 值 


val hash = Utils. nonNegativeHash(filename ) 








val dirld = hash % tachyonDirs. length 


5 
6. 
中 // 哈 希 值 与 tachyonDirs 保存 目录 个 数 的 余数 作为 父 目录 的 id 
8 
9 














// 哈 希 值 与 tachyonDirs 长 度 的 商 再 





求 余 ,得 到 子 目录 的 id 





10. val subDirId = (hash / tachyonDirs. length) % subDirsPerTachyonDir 
11. /从 三 维 数组 中 取出 dirld 和 subDirld 对 应 的 目录 
]| 站 var subDir = subDirs( dirId) (subDirId ) 


13. /如 果 目 录 为 空 
14. if( subDir == null) | 




















15. // 使 用 subDirs( dirId) 上 的 synchronized 同步 块 ,防止 多 线程 同时 操作 

16. subDir = subDirs( dirId ). synchronized | 

17. // 得 到 old 值 

18. val old = subDirs( dirld ) (subDirId ) 

19. // 若 old 值 不 为 空 ,说 明 subDirs( dirld) (subDirId) 对 应 的 目录 不 为 空 ,直接 返回 old 

20. if(old! =null)| 

2 old 

2 | else | 

23. // 若 old 为 空 ,说 明 目 录 还 没有 创建 ,构建 对 应 目录 

24. val path = newTachyonURI(s" $ |tachyonDirs (dirId ) |}/$ |"%02x".format( sub- 
DirId) |} ") 

2 // 使 用 TachyonFS 的 mkdir 方法 创建 path 目录 


26. client. mkdir( path) 


2 // 使 用 TachyonFS 的 getFile 方法 ,得 到 path 目录 对 应 的 TachonFile 对 象 
28. val newDir = client. getFile( path) 
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29. // 将 新 目录 newDir 赋值 给 subDirs( ) (dirld) (subDirId ) 
30. subDirs( dirId) (subDirId) = newDir 

31. // 返 回 newDir 

2 newDir 

33. } 

34. } 

3 } 





36. // 以 subDir 和 fleName 构建 出 file 的 全 路 径 , 创 建 出 TachyonURI 对 象 
3 val filePath = new TachyonURI(s" $ subDir/ $ filename" ) 

38. // 使 用 TachyonFs 的 exist 方法 检测 iePath 是 否 存在 

39. if( | client. exist( filePath) ) | 









































40. // 若 flePath 不 存在 , 则 使 用 TachyonFs 的 createFile 方法 创建 flePath 对 应 的 Tachyon- 
File 

41. client. createFile( filePath ) 

42. } 














43. // 使 用 TachyonFs 的 getFile 方法 ,返回 TachyonURI 对 应 的 TachyonFile 对 象 
44. val file = client. getFile( filePath ) 

45. file 

46. | 








可 以 看 到 getFile 方法 返回 TachyonFile 对 象 。 代 码 中 首先 通过 包 eName 经 哈 希 函数 求 出 
fileName 的 非 负 哈 希 值 ， 映 射 找 出 对 应 的 目录 及 子 目 录 。 使 用 TachyonFs 查看 对 应 的 目录 及 子 
目录 是 否 存在 ， 如 果 不 存在 子 目 录 ， 则 调用 TachyonFs 的 mkdir 方法 创建 子 目 录 。 得 到 文件 的 
完整 路 径 后 ， 先 通过 client. exist 方法 判断 flename 对 应 的 文件 是 否 存在 ， 如 果 不 存在 ， 则 调用 
createFile 方法 创建 文件 ， 和 否则 直接 通过 getFile 方法 返回 该 TachyonFile。 从 这 个 方法 中 ， 清楚 
地 看 到 了 在 Spark 中 是 如 何 使 用 Tachyon API 来 保存 数据 到 分 布 式 内 存 文 件 系统 中 的 ， 相 信 这 
对 于 想 单独 使 用 Tachyon 来 作为 共享 内 存 系统 的 读者 来 说 ， 有 非常 大 的 借鉴 意义 

在 使 用 时 ， 其 实 可 以 借鉴 Spark 中 Tachyon 的 使 用 方式 来 构建 自己 的 内 存 数 据 
共享 应 用 。 介 绍 完 Spark 中 数据 保存 Tachyon 的 方法 后 ， 接 下 来 看 一 下 Spark 中 是 如 何 从 
Tachyon 中 取出 数据 的 。 

2. TachyonBlockManager 从 Tachyon 中 取出 数据 

Spark 中 取出 Tachyon 中 的 数据 也 很 简单 ， 这 里 以 getBytes 为 例 ， 看 一 看 在 Spark 中 是 如 
何 从 Tachyon 中 读 取 数据 的 。getBytes 方法 有 一 个 参数 ， 这 个 参数 为 RDD 产生 的 BlockId 对 
象 ， 从 BlockId 对 象 中 取出 name 属性 ， 该 属性 在 getFile 方法 中 ， 经 由 哈 希 函数 映射 取出 对 
应 的 TachyonFile 文件 。getBytes 方法 的 代码 如 下 。 












































1. override def getBytes( blockId: BlockId) :Option[ ByteBuffer | = | 
多 //getFile 方法 得 到 Tachyon 中 blockld 对 应 的 TachyonFile 对 象 
3 val file = getFile(blockId ) 

4. // 如 果 TachyonFile 为 null 或 者 file 的 hosts 大 小 为 0 ,直接 返回 None 
5 

6 








if(file == null 11 file. getLocationHosts. size ==0) | 


return None 
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人 } 
8. // 得 到 TachyonFile 上 的 输入 流 
9. val js =file. getInStream( ReadType. CACHE) 


10. try | OO 














11. // 文 件 的 长 度 

I val size =file. length 

13. // 构 建 size 大 小 的 字 节 数组 

14. val bs = new Array[ Byte | (size. asInstanceOf[ Int | ) 

15. // 使 用 ByteStreams 的 readFully 方法 ,从 输入 流 将 字 节 信 息 读 和 bs 字 节 数组 中 
16. ByteStreams. readFully (is, bs) 

17. // 将 字 节 数组 包装 成 ByteBuffer 对 象 

18. Some( ByteBuffer. wrap( bs) ) 

19. | catch | 

20. // 捕 获 异常 ,打印 错误 ,返回 None 

2 case NonFatal(e) => 

2 logWarning( s" Failed to get bytes of block $ blockId from Tachyon" ,e) 
2 None 

24. | finally | 

2 // 关 闭 输 入 流 

26. is. close( ) 

27 0 

28. | 


getBytes 方法 接受 一 个 参数 BlockId， 和 putBytes 一 样 ， 需 要 调用 getFile (blockId) 方 
法 ， 返 回 blockld 经 哈 希 映射 所 对 应 的 TachyonFile。 首 先 判 断 getFile 方法 的 返回 值 ， 如 果 该 
返回 值 为 空 或 fle. getLocationHosts 的 大 小 为 0， 直 接 返 回 None; 否则 得 到 该 文件 的 输入 流 ， 
并 通过 输入 流 读 取 数据 到 数组 中 ,返回 读 取 到 的 数据 ， 最 后 关闭 输出 流 。 

Tachyon 作为 一 个 分 布 式 内 存 文件 系统 ， 向 外 提供 了 方便 的 API， 通 过 这 些 API 可 以 很 
方便 地 整合 Tachyon 到 其 他 系统 中 ， 有 关 Tachyon 的 更 多 信息 可 以 到 Tachyon (Alluxio) 的 官 
网 查看 ， 网 址 为 :http://www. alluxio. org。 











小 结 















































本 章 主 要 围绕 Storage 模块 中 的 通信 层 和 存储 层 进行 讲解 ， 在 6. 1 市 讲解 了 Storage 的 定 
义 、 原 理 及 内 部 使 用 的 设计 模式 ; 6. 2 节 是 本 章 最 重要 的 两 个 小 节 ， 在 6. 2. 1 讲解 了 Storage 
模块 的 通信 层 ，6. 2.2 讲解 了 Storage 模块 的 存储 层 。 

Spark 预先 定义 了 StorageLevel， 在 使 用 的 时 候 可 以 直接 通过 StorageLevel 选择 数据 存储 
的 级 别 。 当 然 不 同 的 存储 级 别 对 性 能 及 硬件 设施 都 有 影响 ， 因 此 在 6.3 小 节 详 细 对 比 了 
StorageLevel 的 不 同等 级 ， 在 6. 4 小 节 论 述 了 StorageLevel 对 性 能 的 影响 ,在 6.5 小 节 简 单 介 
绍 了 目前 Spark 中 存储 级 别 为 OFF_HEAP 的 唯一 实现 Tachyon ， 简 单 介 绍 了 其 API 的 使 
用 ， 并 通过 源 代 码 介绍 Tachyon 在 Spark 中 的 使 用 。 
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第 7 普 Shuffle 机 制 


在 大 数据 计算 框架 中 ，Shuffle 阶段 (Phase) 的 设计 优 劣 是 决定 性 能 好 坏 的 关键 因素 之 
一 。 为 了 深入 理解 Shuffle 阶段 的 各 个 细节 ， 并 进一步 在 理解 的 基础 上 优化 代码 ， 减 少 不 必 
要 的 Shuffle 开销 ， 本 章 将 深入 Spark Shuffle 阶段 的 源 代 码 实现 ， 详 细 解 析 SparkShuffle 阶段 
的 实现 细节 ， 主 要 内 容 包括 Shuffle 框架 的 演进 史 、Shuffle 框架 的 可 插 拔 设计 、Shuffle 阶段 
的 数据 读 写 设计 ， 以 及 当前 Spark 中 已 经 支持 的 Shuffle 阶段 的 3 种 设计 与 实现 。 


7 Shuffle 概述 











Shuffle 也 称 为 “ 洗 牌 ”"”， 从 字面 含义 上 理解 ， 就 是 对 数据 进行 重组 。 存 Master 调度 机 制 
的 实现 源 代码 中 ， 也 可 以 看 到 Shuffle 在 数据 重组 上 的 一 个 应 用 场景 ， 代 码 如 下 。 





// Drivers 在 Executors 的 分 配 上 具有 优先 权 


// 对 当前 可 分 配 的 Worker 进行 洗 牌 ,可 以 帮助 Drivers 的 均衡 部 署 
val shuffledWorkers = Random. shuffle( workers) // Randomization helps balance drivers 
for( worker <— shuffledWorkers if worker. state == WorkerState. ALIVE ) | 


A 


其 中 第 4 行 代码 就 是 使 用 了 随机 洗 牌 的 方式 对 数据 进行 重组 ， 重 新 整理 数据 的 顺序 来 实 
现 调度 均衡 的 需求 。 此 处 的 数据 重组 仅仅 是 顺序 上 的 ， 而 对 应 在 MR 框架 中 ， 本 质 上 是 将 不 
同 的 数据 重新 组 织 到 拆 分 的 小 数据 块 中 (所 以 在 某 些 场景 下 (协同 分 区 )， 如 果 可 以 避免 数 
据 重 组 ,或 避免 在 迭代 中 多 次 不 必要 的 数据 重组 ， 在 构建 RDD 时 ， 可 以 避免 使 用 宽 依赖 来 
进行 优化 ) ， 只 是 重组 数据 的 过 程 往往 伴随 着 磁盘 1/0 与 网 络 /0 等 开销 。 

对 应 在 Hadoop MapReduce 框架 或 Spark 框架 中 ，Shuffle 阶段 本 质 上 也 是 对 数据 进行 重 
组 ， 只 是 由 于 分 布 式 计算 的 特性 和 要 求 ， 在 实现 的 细节 上 会 更 加 复杂 。 

在 MapReduce 框架 中 ，Shuffle 阶段 是 连接 Map 和 Reduce 之 间 的 桥梁 ，Map 阶段 通过 
Shuffle 过 程 将 数据 输出 到 Reduce 阶段 中 。 由 于 Shuffle 涉及 磁盘 的 读 写 和 网 络 VO， 因此 
Shuffle 性 能 的 高 低 直接 影响 整个 程序 的 性 能 。Spark 本 质 上 也 是 一 种 MapReduce 框架 ,因此 
也 会 有 自己 的 Shuffle 过 程 实现 。 

在 学 习 Shuffle 的 过 程 中 ， 通 党 都 会 引用 Hadoop MapReduce 框架 中 的 Shuffle 过 程 作为 人 
门 或 比较 ， 同 时 也 会 引用 Hadoop MapReduce 框架 的 Shuffle 过 程 中 常用 的 术语 ， 下 面 参考 网 
络 上 描述 该 过 程 经 典 的 框架 图 ， 如 图 7-1 所 示 。 
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图 7-1 Hadoop MapReduce 框架 中 的 Shuffle 框 








诠 





其 中 ，Shuffle 是 MapReduce 框架 中 的 一 个 特定 阶段 ， 介 于 Map 阶段 和 Reduce 阶段 之 
间 。Map 阶段 负责 准备 数据 ，Reduce 阶段 则 读 取 Map 阶段 所 准备 的 数据 ， 然 后 进一步 对 数 
据 进 行 处 理 。 即 Map 阶段 实现 Shuffle 过 程 中 的 数据 持久 化 〈 即 数据 写 和 人) ， 而 Reduce 阶段 
实现 Shuffle 过 程 中 的 数据 读 取 。 

在 图 7-1 中 ，Mapper 端 与 Reduce 端 之 间 的 数据 交互 通常 都 伴随 着 一 定 的 网 络 IZO， 
此 对 应 数据 的 序列 化 与 压缩 等 技术 也 是 Shuffle 中 必 不 可 少 的 一 部 分 。 可 以 根据 特定 场景 选 
取 合适 的 序列 化 方式 与 压缩 算法 进行 调 优 ， 在 此 仅 给 出 相关 的 配置 属性 的 简单 描述 ， 具 体 如 
表 7-1 所 示 。 





表 7-1 Shuffle 序列 化 方式 与 压缩 算法 的 配置 属性 
配置 属性 默 认 值 描 述 








org. apache. spark. serializer. JavaSeriali- 
ek zer ( 当 使 用 Spark SQL Thrift Server 时 ， 序列 化 器 ， 当 需要 在 网 络 中 传输 或 以 序列 化 方式 缓存 
Shar Se - 默认 为 org. apache. spark. serializer. Kryo- | 时 用 于 序列 化 对 象 所 需 的 类 


Serializer) 




















是 否 对 Map 端 输出 文件 进行 压缩 。 为 了 减少 网 络 IO 
spark. shuffle. compress true 等 ， 通常 会 使 用 压缩 。 对 应 的 压缩 算法 由 spark. io. com- 


pression. codec 指定 























spark. shuffle. spill. : 在 数据 Spill 过 程 中 是 否 进行 压缩 的 控制 。 对 应 的 压 
compress I 缩 算法 由 spark. io. compression. codec 指定 








该 codec 用 于 压缩 内 部 数据 ， 如 RDD 分 区 数据 ， 广 播 
变量 的 数据 及 Shuffle 的 输出 数据 。 默 认 情况 下 ，Spark 提 














spark. io. compression. 供 3 种 codecs: lz4 、lzf 和 snappy。 指 定时 也 可 以 指定 完 
snap & 
codec PPY 整 类 名 。 如 : org. apache. spark. io. LZ4CompressionCodec , 


org. apache. spark. io. LZFCompressionCodec ， 和 org. apache. 


spark. io. SnappyCompressionCodec 











可 以 基于 图 7-1 所 示 的 框架 ， 抽 象 地 理解 Shuffle 阶段 的 实现 过 程 ， 但 在 具体 的 实现 上 ， 
不 同 的 Shuffle 设计 会 有 不 同 的 实现 细节 。 
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7 Shuffle 的 框架 





Shuffle 的 框架 演进 





Spark 的 Shuffle 框架 演进 历史 可 以 从 框架 本 身 的 演进 和 Shuffle 具体 实现 机 制 的 演进 两 部 
分 进行 解析 。 

框架 本 身 的 演进 可 以 从 面向 接口 编程 的 原则 出 发 ， 结 合 Build 设计 模式 进行 理解 。 整 个 
Spark 的 Shuffle 框架 是 从 Spark 1. 1 版 本 开始 ， 提 供 了 便于 测试 和 扩展 的 可 揪 拔 式 框架 。 

而 对 应 在 Shuffle 的 具体 实现 机 制 的 演进 部 分 ， 可 以 跟踪 Shuffle 实现 细节 在 各 个 版 本 中 
的 变更 。 具 体 体现 在 Shuffle 数据 的 写 入 或 读 取 ， 以 及 读 写 相关 的 数据 块 解析 方式 。 下 面 简 
单 描述 一 下 整个 演进 过 程 。 

在 Spark 1. 1 之 前 ，Spark 中 只 实现 了 一 种 Shuffle 方式 ， 即 基于 Hash 的 Shuffle。 在 基于 
Hash 的 Shuffle 的 实现 方式 中 ， 每 个 Mapper 阶段 的 Task 都 会 为 每 个 Reduce 阶段 的 Task 生成 
一 个 文件 ， 通 常会 产生 大 量 的 文件 〈( 即 对 应 为 M xR 个 中 间 文 件 ， 其 中 ，M 表示 Mapper 阶 
段 的 Task 个 数 ，R 表示 Reduce 阶段 的 Task 个 数 ) ， 伴 随 着 大 量 的 随机 磁盘 IO 操作 与 大 量 
的 内 存 开销 。 

为 了 缓解 上 述 问 题 ， 在 Spark 0. 8. 1 版 本 中 为 基于 Hash 的 Shuffle 的 实现 引入 了 Shuffle 
Consolidate 机 制 〈 即 文件 合并 机 制 ) ， 即 将 Mapper 端 生成 的 中 间 文 件 进行 合并 的 处 理 机 制 。 
通过 设置 配置 属性 “spark. shuffle. consolidateFiles” 为 tue， 来 减少 中 间 生 成 的 文件 数量 。 通 
过 文件 合并 ， 可 以 将 中 间 文 件 的 生成 方式 修改 为 每 个 执行 单位 (类似 于 Hadoop 的 Slot) ， 为 
每 个 Reduce 阶段 的 Task 生成 一 个 文件 。 其 中 ， 执 行 单 位 对 应 为 : 每 个 Mapper 阶段 的 Core 
数 /每 个 Task 分 配 的 Core 数 (默认 为 1)。 最 终 可 以 将 文件 个 数 从 M xR 修改 为 Ex C/T x 
R， 其 中 ,下 表示 Executor 个 数 ，C 表示 可 用 Core 个 数 ,T 表示 Task 所 分 配 的 Core 个 数 。 

基于 Hash 的 Shuffle 的 实现 方式 中 ， 生 成 的 中 间 结 果 文 件 的 个 数 都 会 依赖 于 Reduce 阶段 
的 Task 个 数 ， 即 Reduce 端的 并 行 度 ， 因 此 文件 数 仍然 不 可 控 ， 无 法 真正 解决 问题 。 因 此 ， 为 
了 更 好 地 解决 问题 ， 在 Spark 1.1 版 本 引入 了 基于 Sort 的 Shuffle 实现 方式 ， 并 且 在 Spark 1.2 
版 本 之 后 ， 默 认 的 实现 方式 也 从 基于 Hash 的 Shuffle 修改 为 基于 Sort 的 Shuffle 实现 方式 ， 即 使 
用 的 ShuffleManager 从 默认 的 hash 修改 为 sort。 首 先 ， 每 个 Mapper 阶段 的 Task 不 会 为 每 个 Re- 
duce 阶段 的 Task 生成 一 个 单独 的 文件 ;而 是 全 部 写 到 一 个 数据 (Data) 文件 中 ， 同 时 生成 一 
个 索引 (Index) 文件 ，Reduce 阶段 的 各 个 Task 可 以 通过 该 索引 文件 获取 相关 的 数据 。 避 免 产 
生 大 量 文件 的 直接 收益 就 是 降低 随机 磁盘 WO 与 内 存 的 开销 。 最 终生 成 的 文件 个 数 减少 到 
2 MB ， 表 示 每 个 Mapper 阶段 的 Task 分 别 生成 两 个 文件 ， 分 别 为 数据 文件 与 索引 文件 。 

随 着 Tungsten 计划 的 引入 与 优化 ， 从 Spark 1.4 版 本 开始 (Tungsten 计划 目前 在 Spark 
1.5 与 Spark 1.6 两 个 版 本 中 分 别 实现 了 第 一 与 第 二 两 个 阶段 ) ， 在 Shuffle 过 程 中 也 引入 了 基 
于 Tungsten -Sort 的 Shuffle 实现 方式 ， 通 过 Tungsten 项 目 所 做 的 优化 ， 可 以 极 大 地 提高 
Spark 在 数据 处 理 上 的 性 能 。 
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为 了 更 合理 、 更 高 效 地 使 用 内 存 ， 在 Spark 的 Shuffle 实现 方式 演进 过 程 中 ,引进 了 外 部 
排序 等 处 理 机 制 (针对 基于 Sort 的 Shuffle 机 制 。 基 于 Hash 的 Shuffle 机 制 从 最 原始 的 全 部 放 
入 内 存 改 为 记录 级 写 人 ) 。 同 时 ， 为 了 保存 Shuffle 结果 ， 提 高 性 能 ， 以 及 支持 资源 动态 分 配 
等 特性 ， 也 引进 了 外 部 Shuffle 服务 等 机 制 。 


E23 Shuffle 的 框架 内 核 ) 


Shuffle 框架 的 设计 可 以 从 两 方面 去 理解 : 一 方面 为 了 Shuffle 模块 更 加 内 聚 ， 并 与 其 他 
模块 解 耦 ; 另 一 方面 为 了 更 方便 替换 、 测 试 和 扩展 Shuffle 的 不 同 实现 方式 。 从 Spark 1. 1 版 
本 开始 ， 引 进 了 可 播 拔 式 的 Shuffle 框架 (通过 将 Shuffle 相关 的 实现 封装 到 一 个 统一 的 对 外 
接口 ， 提 供 一 种 具体 实现 可 插 拔 的 框架 ) 。Spark 框架 中 ， 通 过 ShuffleManager 来 管理 各 种 不 
同 实现 机 制 的 Shuffle 过程， 由 ShuffleManager 统一 构 建 、 管 理 具体 实现 子 类 来 实现 Shuffle 框 
架 的 可 搬 拔 的 Shuffle 机 制 。 

在 详细 描述 Shuffle 框架 实现 细节 之 前 ， 先 给 出 可 插 拔 式 Shuffle 的 整体 架构 的 类 图 ， 如 
图 7-2 所 示 。 


构建 时 ， 注 册 到 ShuffleManager， 并 得 到 shuffleHandle， 
| ShuffleManager 根 据 shuffleHandler 获 取 Writer 和 Reader 
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ShuffleBlockResolver > et 











人 read(): lterator[Product2[K, C]] | 








| getBlockData{blockld: ShuffleBlockld): ManagedBuffer 
| stop(): Unit 











ShuffleWriter[K, V] | 








| write(records: Iterator[Product2[K, V]]): Unit 
| stop(success: Boolean): Option[MapStatus] 





图 7-2 可 插 拨 式 Shuffle 的 整体 架构 的 类 图 








在 DAG 的 调度 过 程 中 ，Stage 阶段 的 划分 是 根据 是 否 有 Shuffle 过 程 ， 也 就 是 当 存在 
ShuffleDependency 的 宽 依赖 时 ， 需 要 进行 Shuffle， 这 时 会 将 作业 (Job) 划分 成 多 个 Stage。 
相应 的 ， 在 源 代码 实现 中 ， 通 过 在 划分 Stage 的 关键 点 构建 ShuffleDependency 时 一 一 进 
行 Shuffle 注册 ， 获 取 后 续 数 据 读 写 所 需 的 ShuffleHandle。 

stage 阶段 划分 的 详细 过 程 可 以 参考 DAG 调度 音节 的 内 容 ， 最 终 每 个 作业 (Job) 提交 
后 都 会 对 应 生成 一 个 ResultStage 与 若干 个 ShuffleMapStage， 其 中 ResultStage 表示 生成 作业 的 
最 终结 果 所 在 的 Stage。ResultStage 与 ShuffleMapStage 中 的 Task 分 别 对 应 了 ResultTask 与 
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ShuffleMapTask。 一 个 作业 ， 除 了 最 终 的 ResultStage 外 ， 其 他 若干 ShuffleMapStage 中 的 各 个 
ShuffleMapTask 都 需要 将 最 终 的 数据 根据 相应 的 分 区 器 (Partitioner) 对 数据 进行 分 组 (即将 
数据 重组 到 新 的 各 个 分 区 中 ) ， 然 后 持久 化 分 组 后 的 数据 。 相 应 的 ， 每 个 RDD 本 身 记 录 了 
它 的 数据 来 源 ， 在 计算 (compute) 时 会 读 取 所 需 的 数据 ， 对 于 带 有 宽 依 赖 的 RDD ， 读 取 时 
会 获取 在 ShuffleMapTask 中 持久 化 的 数据 。 

从 图 7-2 中 可 以 看 到 ， 外 部 宽 依赖 相关 的 RDD 与 ShuffleManager 之 间 的 注册 交互 ， 通过 
该 注册 ， 每 个 RDD 自 带 的 宽 依赖 ( ShuffleDependency) 内 部 会 维护 Shuffle 的 唯一 标识 信息 
Shuffleld， 以 及 与 Shuffle 过 程 具体 读 写 相 关 的 句柄 ShuffleHandle， 后 续 在 ShuffleMapTask 中 
启动 任务 (Task) 时 ， 可 以 通过 该 句柄 获取 相关 的 Shuffle 写 人 器 实例 ， 实 现 具体 的 数据 磁 
盘 写 操作 。 

而 在 宽 依 赖 (ShuffleDependency) 的 RDD 中 ， 执 行 compute 时 会 去 读 取 上 一 Stage 为 其 
输出 的 Shuffle 数据 ， 此 时 同样 会 通过 该 句柄 获取 相关 的 Shuffle 读 取 器 实例 ， 实 现 具体 数据 
的 读 取 操作 。 需 要 注意 的 是 ， 当 前 Shuffle 的 读 写 过 程 中 ， 与 BlockManager 的 交互 ， 是 通过 
MapOutputTracker 来 跟踪 Shuffle 过 程 中 各 个 任务 的 输出 数据 的 。 在 任务 完成 等 场景 中 ， 会 将 
对 应 的 MapStatus 信息 注册 到 MapOutputTracker 中 ， 而 在 compute 时 的 数据 读 取 过 程 中 ， 也 
会 通过 该 跟踪 器 来 获取 上 一 Stage 的 输出 数据 在 BlockManager 中 的 位 置 ， 然 后 通过 getReader 
得 到 的 数据 读 取 需 ， 从 这 些 位 置 中 读 取 数 据 。 

目前 对 Shuffle 的 输出 进行 跟踪 的 MapOutputTracker 并 没有 和 Shuffle 数据 读 写 类 一 样 ， 
也 封装 到 Shuffle 的 框架 中 。 如 果 从 代码 聚合 与 解 耦 等 角度 出 发 ， 也 可 以 将 MapOutputTracker 
合并 到 整个 Shuffle 框架 中 ， 然 后 在 Shuffle 写 入 带 输 出 数据 之 后 立即 进行 注册 ， 在 数据 读 取 
器 读 取 数据 之 前 获取 位 置 等 〈 但 对 应 的 DAG 等 调度 部 分 也 需要 进行 修改 ) 。 

ShuffleManager 封装 了 各 种 Shuffle 机 制 的 具体 实现 细节 ， 其 包含 的 接口 与 属性 如 下 所 示 。 

1) registerShuffle: 每 个 RDD 在 构建 它 的 父 依 赖 (这 里 特 指 ShufftleDependency) 时 ， 都 
会 先 注 册 到 ShuffleManager ， 获 取 ShuffleHandler， 用 于 后 续 数据 块 的 读 写 等 。 

2) getWriter: 可 以 通过 ShuffleHandler 获取 数据 块 写 和 器， 写 数据 时 通过 Shuffle 的 块 解 
析 器 shuffleBlockResolver 获取 写 和 人 位置 (通常 将 写 和 人 位置 抽 象 为 Bucket， 位 置 的 选择 则 由 洗 
牌 的 规则 即 Shuffle 的 分 区 需 决 定 ) ， 然 后 将 数据 写 和 到 相应 位 置 (理论 上 ,该 位 置 可 以 位 于 
任何 能 存储 数据 的 地 方 ， 包 括 磁盘 、 内 存 或 其 他 存储 框架 等 ， 目 前 在 可 插 拔 框 架 的 几 种 实现 
中 ，Spark 与 Hadoop 一 样 都 采用 了 磁盘 的 方式 进行 存储 ， 主 要 目的 是 为 了 节约 内 存 ， 同 时 提 
高 容错 性 ) 。 

3) getReader: 可 以 通过 ShuffleHandler 获取 数据 块 读 取 需 ， 然 后 通过 Shuffle 的 块 解析 
人 克 shuffleBlockResolver 来 获取 指定 数据 块 。 

4) unregisterShuffle: 与 注册 相对 应 ， 用 于 删除 元 数据 等 后 续 清理 操作 。 

5) shuffleBlockResolver: Shuffle 的 块 解析 器 ， 通 过 该 解析 器 ， 为 数据 块 的 读 写 提供 支撑 
层 ， 便 于 抽象 具体 的 实现 细节 。 
























































Shuffle 框架 的 源 代码 解析 ) 


用 户 可 以 通过 自 定义 ShuffleManager 接口 ， 并 通过 指定 的 配置 属性 进行 设置 ， 也 可 以 通 
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过 该 配置 属性 指定 Spark 已 经 支持 的 ShuffleManager 具体 实现 子 类 。 
在 SparkEnv 源 代码 中 可 以 看 到 设置 的 配置 属性 ， 以 及 当前 在 Spark 的 ShuffleManager 可 
插 拔 框架 中 已 经 提供 的 ShuffleManager 具体 实现 ,代码 如 下 。 





// 用 户 可 以 通过 短 格式 的 命名 来 指定 所 使 用 的 ShuffleManager 


// Let the user specify short names for shuffle managers 


1 

2 

3 

4. ”// 下 面 是 3 种 已 经 支持 的 ShuffleManager, 包 括 hash .sort 及 tungsten - sort 

5. val shortShuffleMgrNames = Map( 

6 "hash" -> "org. apache. spark. shuffle. hash. HashShuffleManager" ， 

7 "sort" —> "org. apache. spark. shuffle. sort. SortShuffleManager" ， 

8 "tungsten — sort" 一 > "org. apache. spark. shuffle. sort. SortShuffleManager" ) 
9 


10.， /指定 ShuffleManager 的 配置 属性 :"spark. shuffle. manager" 
11. // 默 认 情 况 下 使 用 sort, 即 SortShuffleManager 的 实现 
六 val shuffleMgrName = conf. get( " spark. shuffle. manager" ," sort" ) 


























13. val shuffleMgrClass = shortShuffleMgrNames. getOrElse ( shuffleMgrName. toLowerCase, shuf- 
fleMgrName) 
14. val shuffleManager = instantiateClass| ShuffleManager | ( shuffleMgrClass ) 





从 上 面 的 代码 中 可 以 看 出 ，ShuffleManager 是 Spark Shuffle 系统 提供 的 一 个 可 揪 拔 式 接 
口 ， 可 以 通过 "spark. shuffle. manager” 配置 属性 来 设置 自 定义 的 ShuffleManager。 

在 Driver 和 每 个 Executor 的 SparkEnv 实例 化 过 程 中 ， 都 会 创建 一 个 ShuffleManager， 用 
于 管理 块 数据 ， 提 供 集 群 块 数据 的 读 写 ， 包 括 数据 的 本 地 读 写 和 读 取 远程 结 点 的 块 数据 。 

Shuffle 系统 的 框架 可 以 以 ShuffleManager 作为 人口 进行 解析 。 在 ShuffleManager 中 指定 了 
整个 Shuffle 框架 所 使 用 的 各 个 组 件 ， 包 括 如 何 注册 到 ShuffleManager 以 获取 一 个 用 于 数据 读 
写 的 处 理 句 柄 ShuffleHandle， 通 过 ShuffleHandle 获取 特定 的 数据 读 写 接口 : ShuffleWriter 与 
ShuffleReader， 以 及 如 何 去 获 取 块 数据 信息 的 解析 接口 ShuffleBlockResolver。 下 面 通过 源 代 
码 分别 对 这 几 个 比较 重要 的 组 件 进行 解析 。 

1. ShuffleManager 源 代码 解析 

由 于 ShuffleManager 是 Spark Shuffle 系统 提供 的 一 个 可 插 拨 式 接口 ， 已 经 提供 的 具体 实 
现 子 类 或 自 定 义 具 体 实现 子 类 时 ， 都 需要 重 写 ShuffleManager 类 的 抽象 接口 ， 下 面 首先 分 析 
ShuffleManager 的 源 代码 ， 代 码 如 下 。 























package org. apache. spark. shuffle 
import org. apache. spark. |TaskContext,ShuffleDependency| 
/** 


x* Shuffle 系统 的 可 搬 拨 接口 。 在 Driver 和 每 个 Executor 的 SparkEnv 实例 中 创建 
* Pluggable interface for shuffle systems. A ShuffleManager is created in SparkEnv on the 
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* driver and on each executor, based on the spark. shuffle. manager setting. The driver 


# registers shuffles with it,and executors( or tasks running locally in the driver) can ask to 
* read and write data. 
* NOTE :this will be instantiated by SparkEnv so its constructor can take a SparkConf and 
* boolean isDriver as parameters. 
*/ 

private| spark | trait ShuffleManager | 
/六 米 

* 在 Driver 端 向 ShuffleManager 注册 一 个 Shuffle ,获取 一 个 Handle， 

* 在 具体 Task 中 会 通过 该 Handle 来 读 写 数据 























*/ 
def registerShuffleL K,V,C]( 
shuffleld ; Int, 
numMaps: Int, 


dependency: ShuffleDependency| K,V,C | ) :ShuffleHandle 





. /** 获取 对 应 给 定 的 分 区 所 使 用 的 ShuffleWiriter ,该 方法 在 Executor 上 执行 
* 各 个 Map 任务 时 调用 
* Get a writer for a given partition. Called on executors by map tasks. */ 
def getWriter[ K,V | (handle: ShuffleHandle, mapId: Int, context: TaskContext ) : ShuffleWriter 
[K,V] 


/** 
* 获取 在 Reduce 阶段 读 取 分 区 的 ShuffleReader ,对 应 读 取 的 分 区 由 
* [ startPartition to endPartition -1] 区 间 指 定 。 该 方法 在 Executor 上 执行 
* 各 个 Reduce 任务 时 调用 


* Get a reader for a range of reduce partitions( startPartition to endPartition - 1 ,inclusive). 














* Called on executors by reduce tasks. 
*/ 
def getReader[ K,C]( 
handle: ShuffleHandle, 
startPartition : Int, 
endPartition :Int ， 
context :TaskContext ) :ShuffleReader[ K,C] 


。 / 洲 米 


* 该 接口 和 registerShuffle 分 别 负责 元 数据 的 取消 注册 与 注册 

* 调用 unregisterShuffle 接口 时 ,会 移 除 ShuffleManager 中 对 应 的 元 数据 信息 
* Remove a shuffle s metadata from the ShuffleManager. 
* @ return true if the metadata removed successfully ,otherwise false. 


*/ 
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49. def unregisterShuffle( shuffleId : Int ) :Boolean 


50. 

Sl A 洲 迪 

SZ, * 返回 一 个 可 以 基于 块 坐 标 来 获取 Shuffle 块 数据 的 ShuffleBlockResolver O) 
SS 

54. 得 光 

S33 def shuffleBlockResolver:ShuffleBlockResolver 

56. 


SN ZR 和 aE ShuffleManager 

58. * Shut down this ShuffleManager. */ 
59. def stop( ) : Unit 

60. | 


2. ShuffleHandle 源 代 码 解 析 
ShuffleHandle 比较 简单 ， 用 于 记录 Task 与 Shuffle 相关 的 一 些 元 数据 ， 同 时 也 可 以 作为 
不 同 具体 Shuflle 实现 机 制 的 一 种 标志 信息 ， 控 制 不 同 具体 实现 子 类 的 选择 等 。 如 下 所 示 。 
abstract class ShuffleHandle( val shuffleId : Int ) extends Serializable | | 
3.ShuffleWriter 源 代 码 解析 
继承 ShuffleWriter 的 每 个 具体 子 类 会 实现 write 接口 ， 给 出 任务 在 输出 时 的 记录 具体 写 
的 方法 。 如 下 列 代码 所 示 。 


/** 














* Obtained inside a map task to write out records to the shuffle system. 
*/ 
private| spark | abstract class ShuffleWriter[K,V] | 
/** Write a sequence of records to this task s output */ 
@ throws|[ IOException | 
def write( records : Iterator[ Produci2[ K,V |] ] ) :Unit 


0 00 


/ ** Close this writer, passing along whether the map completed */ 
10. def stop( success: Boolean) :Option[ MapStatus | 
11. | 


4. ShuffleReader 源 代 码 解析 
继承 ShuffleReader 的 每 个 具体 子 类 会 实现 read 接口 ， 计 算 时 负责 从 上 一 阶段 Stage 的 输 
出 数据 中 读 取 记录 。 如 下 列 代码 所 示 。 


private| spark | traitShuffleReader[ K,C] | 
/ ** Read the combined key — values for this reduce task */ 
def read( ) :Iterator[ Product2[K,C]] 


Ye 


* Close this reader. 


1 
2 
3 
4. 
5 
6 
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人 * TODO: Add this back when we make theShuffleReader a developer API that others can implement 
8. * (at which point this will likely be necessary ). 

9. */ 

10. // def stop( ) :Unit 

11. | 


5S.ShuffleBlockResolver 源 代码 解析 
ShuffleBlockResolver 的 源 代码 如 下 所 示 。 


























1l. /i** 

2. ”* 该 特质 的 具体 实现 子 类 知道 如 何 通 过 一 个 逻辑 Shuffle 块 标识 信息 来 获取 一 个 
3. * 块 数据 。 具 体 实现 可 以 使 用 文件 或 文件 段 来 封装 Shuffle 的 数据 。 这 是 获取 Shuffle 块 
4. * 数据 时 所 使 用 的 抽象 接口 ,在 BlockStore 中 使 用 

二 

6. 

7 

8. 

9. */ 

10. trait ShuffleBlockResolver | 

由 由 typeShuffleld = Int 

2 

3 ] 米 米 

14. + 获取 指定 块 的 数据 。 如 果 指 定 块 的 数据 无 法 获取 , 则 抛 出 异常 
ls 

16. 

17. */ 

18. def getBlockData(blockId:ShuffleBlockId) :ManagedBuffer 

19 

20. def stop( ) :Unit 

到 


继承 ShuffleBlockResolver 的 每 个 具体 子 类 会 实现 getBlockData 接口 ， 给 出 具体 的 获取 块 
数据 的 方法 。 

目前 在 ShuffleBlockResolver 的 各 个 具体 子 类 中 ， 除 了 给 出 获取 数据 的 接口 之 外 ， 通 常会 
提供 如 何 解 析 块 数据 信息 的 接口 ， 即 提供 了 写 数据 块 时 的 物理 块 与 逻辑 块 之 间 映 射 关系 的 解 
析 方 法 。 


Shuffle 的 注册 ) 


在 图 7-2 中 可 以 看 到 ， 当 构建 一 个 宽 依赖 ( ShuffleDependency) 的 RDD 时 , 该 RDD 需 
要 向 ShuffleManager 注册 。 之 所 以 在 构建 宽 依赖 时 注册 ， 其 原因 在 于 DAG 调度 器 中 的 Stage 
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是 根据 宽 依 赖 进行 划分 的 ， 而 对 应 的 宽 依赖 类 目前 仅 有 ShuffleDependency。 
对 应 图 7-2 中 与 注册 相关 的 具体 代码 如 下 。 























1. class ShuffleDependency[ K:ClassTag,V :ClassTag,C:ClassTag | ( 
2 @ transient private val _rdd: RDD[ _ < :Product2[K,V]]， 
3 val partitioner: Partitioner, 

4. val serializer: Option| Serializer | = None, 

Ss val keyOrdering: Option[ Ordering[ K | ] = None， 

6. val aggregator: Option|[ Aggregator[ K,V,C| | = None, 

7: val mapSideCombine: Boolean = false ) 

8. extends Dependency[ Product2[K,V]] | 

9. 

10. // 唯 一 标识 信息 ,可 以 看 到 ,是 通过 rdd 的 上 下 文 去 获取 的 ， 
11. ”// 因 此 针对 特定 的 rdd, 每 个 shuffleld 值 都 是 唯一 的 

12. val shuffleld:Int =_rdd. context newShuffleId( ) 

13 





14. ”人 获取 ShuffleHandle 实例 ,后 续 获 取 Shuffle 写 和 人 需 与 读 取 融 时 需要 
15. val shuffleHandle:ShuffleHandle = _rdd. context. env. shuffleManager. registerShuffle( 





























16. shuffleld,_rdd. partitions. size ,this ) 

jl 

18. ”// Shuffle 数据 清理 器 的 设置 ,可 以 扩展 到 当 使 用 外 部 Shuffle 服务 时 ,数据 如 何 清理 等 
19. _rdd. sparkContext. cleaner. foreach( _. registerShuffleForCleanup( this) ) 

20. | 


在 代码 中 可 以 看 到 ， 唯 一 标识 信息 shuffleld 是 通过 RDD 的 上 下 文 来 获取 的 ; 另外 Shuf- 
fleManager 也 是 在 当前 SparkEnv 的 实例 中 获取 ， 然 后 注册 到 SparkEnv 中 的 ShuffleManager 
实例 。 











用 Shuffle 读 写 数据 的 源 代码 解析  ) 





1.，Shuffle 写 数 据 的 源 代码 解析 
从 Spark Shuffle 的 整体 框架 中 可 以 看 到 ， 在 ShuffleManager 中 提供 了 Shuffle 相关 数据 块 
的 写 人 与 读 取 ， 即 对 应 的 接口 getWriter 与 getReader。 

在 解析 Shuffle 框架 数据 读 取 过 程 中 ， 可 以 构建 一 个 具有 ShuffleDependency 的 RDD， 查 
看 在 执行 过 程 中 ，Shuffle 框架 中 的 数据 读 写 接口 getWriter 与 getReader 如 何 使 用 ， 通 过 这 种 
具体 案例 的 方式 来 加 深 对 源 代码 的 理解 。 

Spark 中 Shuffle 具体 的 执行 机 制 可 以 参考 本 书 的 其 他 章节 ， 在 此 仅 分 析 与 Shuffle 直接 相 
关 的 内 容 。 通 过 DAG 调度 机 制 的 解析 可 以 知道 ，Spark 中 的 一 个 作业 可 以 根据 宽 依赖 切 分 
Stage ， 而 在 Stage 中 ， 相 应 的 Task 也 包含 两 种 ， 即 ResultTask 与 ShuffleMapTask。 其 中 ,一 
个 ShuffleMapTask 会 基于 ShuffleDependency 中 指定 的 分 区 器 将 一 个 RDD 的 元 素 拆 分 到 多 个 
bucket 中 ， 此 时 通过 ShuffleManager 的 getWriter 接口 来 获取 数据 与 bucket 的 映射 关系 。 而 
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ResultTask 对 应 的 是 一 个 将 输出 返回 给 应 用 程序 Driver 端的 Task， 在 该 Task 执行 过 程 中 ， 最 





终 都 会 调用 RDD 的 compute 对 内 部 数据 进行 计算 ， 而 在 带 有 ShuffleDependency 的 RDD 中 ， 
在 compute 计算 时 ， 会 通过 ShuffleManager 的 getReader 接口 获取 上 一 个 Stage 的 Shuffle 输出 
结果 来 作为 本 次 Task 的 输入 数据 。 

首先 查看 ShuffleMapTask 中 的 数据 写 流程 ， 具 体 代 码 如 下 。 








override def runTask( context: TaskContext) :MapStatus = | 


1 
2 a 
3. // 首 先 从 SparkEnv 获取 ShuffleManager 

4. ”// 然 后 从 ShuffleDependency 中 获取 注册 到 ShuffleManager 时 所 得 到 的 shuffleHandle 
5. /根据 shuffleHandle 和 当前 Task 对 应 的 分 区 ID ,获取 ShuffleWriter 
6 

7 

8 

9 








// 最 后 根据 获取 的 ShuffleWriter, 调 用 其 write 接口 , 写 入 当前 分 区 的 数据 
var writer: ShuffleWriter[ Any, Any | = null 


try | 
val manager = SparkEnv. get. shuffleManager 
10. writer = manager. getWriter[ Any, Any | ( dep. shuffleHandle ,partitionId , context ) 
11. writer. write ( rdd. iterator ( partition , context ) . asInstanceOf [ Tterator| _ < : Product2 [ Any, 
Any| |]) 
12 writer. stop( success = true ). get 
3 | catch | 
14. 
15. | 
16. | 


2. Shuffle 读数 据 的 源 代码 解析 

对 应 的 数据 读 取 器 ， 从 RDD 的 5 个 抽象 接口 可 知 ，RDD 的 数据 流 最 终 会 经 过 算 子 操 
作 ， 即 RDD 中 的 compute 方法 。 下 面 以 包含 宽 依 赖 的 RDD、CoGroupedRDD 为 例 ， 查 看 如 何 
获取 Shuffle 的 数据 。 具 体 代码 如 下 。 





1. /对 指定 分 区 进行 计算 的 抽象 接口 ,以 下 为 CoGroupedRDD 具体 子 类 中 该 方法 的 实现 

2. override def compute( s:Partition, context:TaskContext) : Iterator[ ( K, Array| Iterable[ _ |]] ) ] =! 
本 val split = s. asInstanceOf[ CoGroupPartition | 

4. val numRdds = dependencies. length 

5. 

6. // A list of( rdd iterator, dependency number) pairs 

7. val rddlterators = new ArrayBuffer[ (Tterator| Product2[ K, Any| | ,Int) |] 

8. for((dep,depNum) <— dependencies. zipWithIndex) dep match | 

9. case oneToOneDependency: OneToOneDependency|[ Product2| K, Any| | @ unchecked => 
10. val dependencyPartition = split. narrowDeps( depNum). get. split 
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11. // Read them from the parent 
2 val it = oneToOneDependency. rdd. iterator( dependencyPartition , context ) 
13. rddlterators + = ( (it, depNum) ) 


14. O) 


15. case shuffleDependency:ShuffleDependency[ _,_,_| => 
16.// 首 先 从 SparkEnv 获取 ShuffleManager 











17. // 然 后 从 ShuffleDependency 中 获取 注册 到 ShuffleManager 时 
18. /所 得 到 的 shuffleHandle。 根 据 shuffleHandle 和 当前 Task 对 应 的 分 区 ID， 
19. // 获 取 ShuffleReader 


20. // 最 后 根据 获取 的 ShuffleReader, 调 用 其 read 接口 , 读 取 Shuffle 的 Map 输出 
21. val 让 = SparkEnv. get shuffleManager 


22. . getReader ( shuffleDependency. shuffleHandle ,split index , split. index + 1 ,context ) 
23: .read( ) 

24. rddlterators + = ( (it, depNum) ) 

25) } 

26. 

2 val map = createExternal Map( numRdds) 

28. for( (it, depNum) <— rddlIterators ) | 

29. map. insertAll(it. map( pair => (pair. _1 ,new CoGroupValue( pair. _2,depNum) ) ) ) 
30. } 

31. context. taskMetrics( ). incMemoryBytesSpilled( map. memoryBytesSpilled ) 

3 context. taskMetrics( ). incDiskBytesSpilled( map. diskBytesSpilled ) 

33. context. internal MetricsToAccumulators( 

34. InternalAccumulator. PEAK_EXECUTION_MEMORY ). add( map. peak MemoryUsedBytes) 
35. new Interruptiblelterator( context, 

36. map. iterator. asInstanceOf| Iterator[ ( K, Array| lterable[ _] ] ) ] 1) 

3 } 


从 代码 中 可 以 看 到 ， 宽 依赖 的 RDD 的 compute 操作 中 ， 最 终 是 通过 SparkEnv 中 的 Shuf- 
fleManager 实例 的 getReader 方法 ， 获 取 数 据 的 读 取 吕 的， 然后 再 次 调用 读 取 器 的 read 方法 
读 取 指定 分 区 范围 的 Shuffle 数据 。 











注意 ， 是 宽 依赖 的 RDD， 而 非 ShuffleRDD。 除 了 ShuffleRDD 之 外 ,还 有 其 他 RDD 也 可 以 是 宽 依赖 ， 例 
如 前 面 给 出 的 CoGroupedRDD。 











目前 支持 的 几 种 具体 Shuffle 实现 机 制 在 读 取 数 据 的 处 理 上 都 是 一 样 的 ， 从 源 代 码 角度 
可 以 看 到 ， 当 前 继承 了 ShuffleReader 这 一 数据 读 取 器 的 接口 的 具体 子 类 只 有 BlockStoreShuf 
fleReader， 因 此 本 章 内 容 仅 在 此 对 各 种 Shuffle 实现 机 制 的 数据 读 取 进行 解析 ， 后 续 各 实现 机 
制 中 不 再 重复 描述 。 

源 代码 解析 的 第 一 步 是 查看 该 类 的 描述 信息 ， 具 体 如 下 。 
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l. /A*¥** 
2. ”* 通 过 从 其 他 结 点 上 请 求 读 取 Shuffle 数据 来 接收 并 读 取 指定 范围 [起 始 分 区 ,结束 分 

















区 ) 一 一 对 应 为 左 闭 右 开 区 间 。 





*/ 


从 注释 上 可 以 看 出 ， 读 取 需 负责 上 一 Stage 为 下 一 Stage 输出 数据 块 的 读 取 。 从 前 面 对 
ShuffleReader 接口 的 解析 可 知 ， 继 承 的 具体 子 类 需要 实现 真正 的 数据 读 取 操作 ， 即 实现 read 
方法 。 因 此 该 方法 是 需要 重点 关注 的 源 代码 ， 一 些 关键 的 代码 如 下 。 











1. /** 为 该 Reduce 任务 读 取 并 合并 key - values 值 
之 */ 

3 override def read( ) :Iterator[ Product2[ K,C]]=| 

4 // 真 正 的 数据 Iterator 读 取 是 通过 ShuffleBlockFetcherlterator 来 完成 的 
3 val blockFetcherltr = new ShuffleBlockFetcherlterator( 
6 

% 

8 

9 




















context, 
blockManager. shuffleClient, 
block Manager, 








lL // 可 以 看 到 , 当 ShuffleMapTask 完成 后 注册 到 mapOutputTracker 的 元 数据 信息 
10. // 同 样 会 通过 mapOutputTracker 来 获取 ,在 此 同时 还 指定 了 获取 的 分 区 范 目 
11. // 通 过 该 方法 的 返回 值 类 型 
12. mapOutputTracker. getMapSizesByExecutorId( handle. shuffleld , startPartition ,endPartition ) ， 








ey 

















13. // Note:we usegetSizeAsMb when no suffix is provided for backwards compatibility 
14. // 默 认 读 取 时 的 数据 大 小 限制 为 48M ,对 应 后 续 并 行 的 读 取 ， 

15. // 都 是 一 种 数据 读 取 的 控制 策略 ,一 方面 可 以 避免 目标 机 带 占 用 过 多 带宽 ， 

16. // 同 时 也 可 以 启动 并 行 机 制 ,加 快 读 取 速度 








PR 














17. SparkEnv. get. conf. getSizeAsMb ( " spark. Reduce. maxSizeInFlight" ," 48m") * 1024 * 
1024) 

18. 

19. // Wrap the streams for compression based on configuration 





[| 





20.// 在 此 针对 前 面 获 取 的 各 个 数据 块 唯一 标识 ID 信息 及 其 对 应 的 输入 流 进 行 处 到 
21. valw rappedStreams = blockFetcherltr. map | case(blockId ,inputStream ) => 

2 blockManager. wrapForCompression( blockId ,inputStream ) 

凡人 


25. /对 读 取 到 的 数据 进行 聚合 处 理 

26. val aggregatedlIter: Iterator| Product2[ K,C | | =if( dep. aggregator. isDefined ) | 

2 // 如 果 在 Map 端 已 经 做 了 聚合 的 优化 操作 , 则 对 读 取 到 的 聚合 结果 进行 聚合 ， 
28. /注意 此 时 的 聚合 操作 与 数据 类 型 和 Map 端 未 做 优化 时 是 不 同 的 

29. if( dep. mapSideCombine ) | 


30. // We are reading values that are already combined 





31. 
2, 
33. 
34. 
35. 
36. 
5 
38. 
39. 
40. 
41. 
42. 
43. 
44. 
45. 
46. 
47. 
48. 
49. 
50. 
51. 
5 
53. 
54. 
55. 
56. 
5 
58. 
59. 
60. 
61. 
(ser) ) 
63. 
64. 
65. 
66. 
67. 
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val combinedKeyValueslterator = interruptiblelter. asInstanceOf| Iterator[ (下 ,C) ] ] 

// 针 对 Map 端 各 分 区 对 Key 进行 合并 后 的 结果 再 次 聚合 ， 

//Map 的 合并 可 以 大 大 减少 网 络 传输 的 数据 量 

dep. aggregator. get combineCombinersByKey( combinedKeyValuesIterator ,context ) O) 





| else | 


// We don t know the value type,but also don t care ——the dependency * should * 
// have made sure its compatible w/ this aggregator, which will convert the value 

// type to the combined type C 

val keyValuesIterator = interruptiblelter. asInstanceOf| Iterator[ (K, Nothing) ] ] 


// 针 对 未 合并 的 keyValues 的 值 进行 聚合 
dep. aggregator. get. combineValuesByKey( keyValueslterator ,context ) 


| 


| else | 
require( ldep. mapSideCombine," Map — side combine without Aggregator specified!" ) 
interruptiblelter. asInstanceOf[ Tterator| Product2[ K,C]]] 


// 在 基于 Sort 的 Shuffle 实现 过 程 中 ,默认 仅仅 是 基于 PartitionId 进行 排序 ， 
// 在 分 区 的 内 部 数据 是 没有 排序 的 ,因此 添加 了 keyOrdering 变量 ， 
// 提 供 是 否 需 要 针对 分 区 内 的 数据 进行 排序 的 标识 信息 
// Sort the output if there is a sort ordering defined. 
dep. keyOrdering match | 

case Some( keyOrd: Ordering[ K] ) => 





// 为 了 减少 内 存 的 压力 ,避免 GC 开销 ,引入 了 外 部 排序 器 对 数据 进行 排序 
// 当 内 存 不 足以 容纳 排序 的 数据 量 时 ,会 根据 配置 的 spark. shuffle. spill 属性 
// 来 决定 是 否 需 要 spill 到 磁盘 中 ,默认 情况 下 会 打开 sp 记 开关， 
// 若 不 打开 ,在 数据 量 比 较 大 时 会 引发 内 存 洲 出 问题 ( Out of Memory ,OOM ) 
//Create an ExternalSorter to sort the data. Note that if spark. shuffle. spill is disabled, 





上 


// theExternalSorter won t spill to disk. 
val sorter = 


new ExternalSorter [ K, C, C ] (context, ordering = Some ( keyOrd ) , serializer = Some 


case None => 


// 不 需要 排序 分 区 内 部 数据 时 直接 返 





回 


aggregatedIter 





下 面 进一步 解析 数据 读 取 的 部 分 细节 ， 首 先是 数据 块 获取 ， 读 取 ShuffleBlockFetcherlter- 
ator 类 ， 在 类 的 构造 体 中 调用 了 initialize 方法 (构造 体 中 的 表达 式 会 在 构造 实例 时 执行 )， 
该 方法 中 会 根据 数据 块 所 在 位 置 (本 地 结 点 或 远程 结 点 ) 分 别 进行 读 取 ， 其 中 的 关键 代码 
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如 下 。 


privatel this | def initialize( ) :Unit = | 


// 本 地 数据 与 远程 数据 的 读 取 方 式 不 同 ,因此 先进 行 拆 分 ， 
// 注 意 拆 分 时 会 考虑 一 次 获取 的 数据 大 小 ( 拆 分 时 会 同时 考虑 并 行 数 ) 封装 请 求 ， 
// 最 后 会 将 剩余 不 足 该 大 小 的 数据 获取 也 封装 为 一 个 请 求 
// Split local and remote blocks. 





val remoteRequests = splitLocalRemoteBlocks( ) 
// Add the remote requests into our queue in a random order 
// 存 人 需要 远程 读 取 的 数据 块 请 求 信息 


fetchRequests ++ = Utils. randomize( remoteRequests) 








SN ONT OA pn eS Dg 


SS 


13. // Send out initial requests for blocks ,up to ourmaxBytesInFlight 


14. // 发 送 数 据 获 取 请 求 






































j fetchUpToMaxBytes( ) 

16. …: 

17. // 除 了 远程 数据 获取 之 外 ,下 面 是 获取 本 地 数据 块 的 方法 调用 
18. // Get Local Blocks 

19. fetchLocalBlocks( ) 

20. 

21. | 





与 Hadoop 一 样 ，Spark 计算 框架 也 是 基于 数据 本 地 性 ， 即 移动 计算 而 非 移动 数据 的 原则 ， 
此 在 获取 数据 块 时 ， 也 会 考虑 数据 本 地 性 ， 尽 量 从 本 地 读 取 已 有 的 数据 块 ， 然 后 再 远程 读 取 。 

另外 ， 数 据 块 的 本 地 性 是 通过 ShuffleBlockFetcherlterator 实例 构建 时 所 传人 的 位 置信 息 
来 判断 的 ， 而 该 信息 由 MapOutputTracker 实例 的 getMapSizesByExecutorld 方法 提供 。 可 以 参 
考 该 方法 的 返回 值 类 型 查看 相关 的 位 置信 息 ， 返 回 值 类 型 为 : Seq[ ( BlockManagerld, Seq 
| (Blockld, Long) ] ) | ， 县 其 中 Block Managerld 是 BlockManager 的 唯一 标识 信息 县 ，BlockId 是 数 
据 块 的 唯一 信息 ， 对 应 的 Seq[ (BlockId,Long) ] ) 表 示 一 组 数据 块 标识 ID 及 其 数据 块 大 小 的 
元 组 信息 。 

最 后 简单 分 析 一 下 如 何 设置 分 区 内 部 的 排序 标识 ， 当 需要 对 分 区 内 的 数据 进行 排序 时 ， 
会 设置 RDD 中 的 宽 依 赖 (ShuffleDependency) 实例 的 keyOrdering 变量 。 下 面 以 基于 排序 的 
OrderedRDDFunctions 提供 的 sortByKey 方法 为 例 给 出 解析 ， 具 体 代 码 如 下 。 





























1 def sortByKey( ascending: Boolean = true ,numPartitions :Int = self. partitions. length ) 
2 :RDD[ (K,V) ] = self. withScope 

3 | 

4. /注意 ,这 里 设置 了 该 方法 构建 的 RDD 所 使 用 的 分 区 器 
5 

6 





























// 根据 Range 而 非 Hash 进行 分 区 ,对 应 的 Range 信息 需要 计算 并 将 结果 
// 反 馈 到 Driver 端 ,因此 对 应 调用 RDD 中 的 Action, 即 会 触发 一 个 Job 的 执行 
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7. val part = new RangePartitioner( numPartitions ,self,ascending ) 


8. // 在 构建 RDD 实例 之 后 ,设置 Key 的 排序 算法 , 即 Ordering 实例 
9. new ShuffledRDD[ K,V,V | (self, part) 
10. . setKeyOrdering( if( ascending ) ordering else ordering. reverse) O) 


i 


当 需 要 对 分 区 内 部 的 数据 进行 排序 时 ， 构 建 RDD 的 同时 会 设置 Key 值 的 排序 算法 ， 结 
合 前 面 的 read 方法 中 的 第 52 行 代 码 ， 当 指定 Key 值 的 排序 算法 时 ， 就 会 使 用 外 部 排序 器 对 
分 区 内 的 数据 进行 排序 。 





基于 Hash 的 Shuffle 





在 Spark 1.1 之 前 ，Spark 中 只 实现 了 一 种 Shuffle 方式 ， 即 基于 Hash 的 Shuffle。 在 
Spark 1. 1 版 本 引入 了 基于 Sort 的 Shuffle 实现 方式 后 ， 并 且 在 Spark 1. 2 版 本 之 后 ， 默 认 的 实 
现 方式 从 基于 Hash 的 Shuffle 修改 为 基于 Sort 的 Shuffle 实现 方式 ， 即 使 用 的 ShuffleManager 
从 默认 的 hash 修改 为 sort。 

Spark 之 所 以 一 开始 就 提供 基于 Hash 的 Shuffle 实现 机 制 ， 其 主要 目的 之 一 就 是 为 了 避 
免 不 必 要 的 排序 (这 也 是 Hadoop Map Reduce 被 人 所 诉 病 的 地 方 ， 将 Sort 作为 固定 步骤 ， 导 
致 了 许多 不 必要 的 开销 ) 。 但 基于 Hash 的 Shuffle 实现 机 制 在 处 理 超大 规模 数据 集 时 ， 由 于 
过 程 中 会 产生 大 量 的 文件 ， 导 致 过 度 的 磁盘 IO 开销 和 内 存 开销 ， 会 极 大 地 影响 性 能 。 

但 在 一 些 特定 的 应 用 场景 下 ， 采 用 基于 Hash 的 实现 Shuffle 机 制 的 性 能 会 超过 基于 Sort 
的 Shuffle 实现 机 制 。 关 于 基于 Hash 与 基于 Sort 的 Shuffle 实现 机 制 的 性 能 测试 方面 ， 可 以 人 参 
考 Spark 创始 人 之 一 ReynoldXin 所 给 的 测试 : “sort - basedshuffle has lower memory usage and 
seems to outperformhash - based in almost allof our testing” 。 

相关 数据 可 以 参考 https://issues. apache. org/jira/ browse/ SPARK -3280 。 

因此 ， 在 Spark 1. 2 版 本 中 修改 为 默认 基于 Sort 的 Shuffle 实现 机 制 时 ， 同 时 也 给 出 了 特 
定 应 用 场景 下 回 退 的 机 制 ， 具 体 可 以 参考 7.4 节 基 于 Sort 的 Shuffle 实现 机 制 。 
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1. 基于 Hash 的 Shuffle 实现 机 制 的 内 核 框架 

基于 Hash 的 Shuffle 实现 ，ShuffleManager 的 具体 实现 子 类 为 HashShuffleManager， 对 应 
的 具体 实现 机 制 如 图 7-3 所 示 。 

其 中 HashShuffleManager 是 ShuffleManager 的 基于 Hash 实现 方式 的 具体 实现 子 类 。 数 据 
块 的 读 写 分 别 由 BlockStoreShuffleReader 与 HashShuffleWriter 实现 ， 数 据 块 的 文件 解析 器 则 由 
具体 子 类 FileShuffleBlockResolver 实现 ，BaseShuffleHandle 是 ShuffleHandle 接口 的 基本 实现 ， 
保存 Shuffle 注册 的 信息 。 

HashShuffleManager 继承 自 ShuffleManager， 对 应 实现 了 各 个 抽象 接口 ， 基 于 Hash 的 
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HashShuffleManager 





一 -一 一 全 registerShuffle[K, V, C] 

















getWriter[K，V] 
getReader[K，C] 
unregisterShuffle 
shuffleBlockResolver 
1:1 _ stop0 
> BaseShuffleHandle 
> BlockStoreShuffleReader 
| HashShuffleWrit 
FileShuffleBlockResolver 一 ee 


图 7-3 基于 Hash 的 Shuffle 实现 机 制 的 内 核 框架 





Shuffle 内 部 使 用 的 各 组 件 的 具体 子 类 如 下 。 


1) BaseShuffleHandle: 携带 了 Shuffle 最 基本 的 元 数据 信息 ， 包 括 shuffleld 、numMaps 和 
dependency。 


2) BlockStoreShuffleReader: 负责 写 入 的 Shuffle 数据 块 的 读 操作 。 
二 
页 


3) FileShuffleBlockResolver: 负责 管理 为 Shuffle 任务 分 配 基 于 磁盘 的 块 数据 的 Writer。 
每 个 Shuffle 任务 为 每 个 Reduce 分 配 一 个 文件 。 


4) HashShuffleWriter: 负责 Shuffle 数据 块 的 写 操 作 。 
在 此 与 解析 整个 Shuffle 过 程 一 样 ， 以 HashShuffleManager 类 作为 入 口 进行 解析 。 
首先 来 看 一 下 HashShuffleManager 具体 子 类 的 注释 ， 代 码 如 下 。 








有 


* 使 用 Hash 的 ShuffleManager 具体 实现 子 类 ,针对 每 个 Mapper 都 会 为 各 个 Reduce 分 
* 区 构建 一 个 输出 文件 (也 可 能 是 多 个 任务 复 用 文件 ) 





























O 


1 
之 
3 
4 
0 */ 
% 
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private| spark | class HashShuffleManager( conf: SparkConf) extends ShuffleManager with Logging | 


2. 基于 Hash 的 Shuffle 实现 方式 一 

为 了 避免 Hadoop 中 基于 Sort 方式 的 Shuffle 所 带 来 的 不 必要 的 排序 开销 ，Spark 在 
开始 时 采用 了 基于 Hash 的 Shuffle 方式 。 但 这 种 方式 存在 很 多 缺陷 ， 这 些 缺 陷 大 部 分 是 
由 于 基于 Hash 的 Shuffle 实现 过 程 中 创建 了 太 多 的 文件 所 造成 的 。 在 这 种 方式 下 ， 每 个 
Mapper 端的 Task 运行 时 都 会 为 每 个 Reduce 端的 Task 生成 一 个 文件 ， 具 体 如 图 7-4 
所 示 。 
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本 地 文件 系统 


Executor-Mapper shuffle_shuffleld_1_1 
[> shuffle_shuffleld_1_2 


Map-Task-1 shuffle_shuffleld 1_R 


Map-Task-2 = 性 shuffle shuffleld_ 2_1 


shuffle_shuffleld_2_ 2 


Map-Task-M shuffle_shuffleld M_1 
> shuffle_shuffleld M_2 Reducer 端 的 
分 区 个 数 


shuffle_shuffleld M_R 





图 7-4 基于 Hash 的 Shuffle 实现 方式 一 文件 的 输出 细节 图 


图 7-4 中 ，Executor - Mapper 表示 执行 Mapper 端的 Task 的 工作 点 ， 可 以 分 布 到 集群 中 
的 多 台 机 需 结 点 上 ， 并 且 可 以 以 不 同 的 形式 出 现 ， 比 如 以 Spark Standalone 部 署 模式 中 的 Ex- 
ecutor 出 现 ， 也 可 以 以 Spark On Yarm 部 署 模 式 中 的 容器 形式 出 现 ， 关 键 是 它 代表 了 实际 执 
行 Mapper 端的 Tasks 的 工作 点 的 抽象 概念 。 其 中 ，M 表示 Mapper 端的 Task 的 个 数 ，R 表示 
Reduce 端的 Task 的 个 数 。 

对 应 在 右 侧 的 本 地 文件 系统 是 在 该 工作 点 上 所 生成 的 文件 ， 其 中 R 表示 Reduce 端的 分 
区 个 数 。 生 成 的 文件 名 格式 为 :“shuffle_shuffleId_mapld_reduceld”, 例 如， 其 中 的 “shuffle_ 
shuffleld_1_1” 表 示 maplId 为 1， 同时 reduceld 也 为 1。 

在 Mapper 端 ， 每 个 分 区 对 应 启动 一 个 Task ， 而 每 个 Task 会 为 每 个 Reduer 端的 Task 生 
成 一 个 文件 ， 因 此 最 终生 成 的 文件 个 数 为 M x R。 

由 于 这 种 实现 方式 下 ， 对 应 生成 文件 的 个 数 仅仅 与 Mapper 端 和 Reduce 端 各 自 的 分 区 数 
有 关 ， 因 此 图 7-4 中 将 Mapper 端的 全 部 M 个 Task 抽象 到 一 个 Executor - Mapper 中 ， 实 际 场 
景 中 通常 是 分 布 到 集群 中 的 各 个 工作 点 中 。 

生成 的 各 个 文件 位 于 本 地 文件 系统 的 指定 目录 中 , 该 目录 地 址 由 配置 


“spark. local. dir” 设 置 。 











性 


al 





说 明 : 分 区 数 与 Task 数 一 个 是 静态 的 数据 分 抉 个 数 ， 一 个 是 数据 分 块 对 应 执行 的 动态 任务 个 数 的 描述 ， 
因此 在 特定 的 描述 个 数 的 场景 下 ， 两 者 是 一 样 的 。 








3. 基于 Hash 的 Shuffle 实现 方式 二 
为 了 减少 图 7-4 中 所 生成 的 文件 个 数 ， 对 基于 Hash 的 Shuffle 实现 方式 进行 了 优化 ， 引 
和 人 了 文件 合并 的 机 制 ， 该 机 制 设置 的 开关 为 配置 属性 “spark. shuffle. consolidateFiles”。 在 引 
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入 文件 合并 的 机 制 之 后 ， 当 设置 配置 属性 为 tue， 即 启动 文件 合并 时 ， 在 Mapper 端的 输出 
文件 会 进行 合并 ， 在 一 定 程 度 上 可 以 大 量 减 少 文件 的 生成 ， 降 低 不 必要 的 开销 。 文 件 合并 的 
实现 方式 可 以 参考 图 7-5。 


Executor-Mapper merged_shufflc_shuffleld_1_1 
4 merged_shufflc_shuffleld_2_1 


Map-Task-1 


Map-Task-2 ~ 





merged_shufflc_shuffleld_1_2 


merged_shuffle_shuffleld 2_2 


Map-Task-C/T 


Map-Task-(C/T+1) 


Map-Task-(C/T+2) Re 
merged_shuffle_shuffleld_2_C/T Reducer 端 的 
分 区 个 数 


merged_shuffle_shuffleld_R_C/T 











图 7-5 基于 Hash 的 Shuffle 的 合并 文件 机 制 的 输出 细节 图 





图 7-5 中 ，Executor - Mapper 表示 集群 中 分 配 的 某 个 工作 点 ， 其 中 ，C 表示 在 该 工作 点 
上 所 分 配 到 的 内 核 (Core) 个 数 , T 表 示 在 该 工作 点 上 为 每 个 Task 所 分 配 的 的 内 核 个 数 。 
C/T 表示 在 该 工作 点 上 调度 时 最 大 的 Task 并 行 个 数 。 

对 应 在 右 侧 的 本 地 文件 系统 是 在 该 工作 点 上 所 生成 的 文件 ， 其 中 R 表示 Reduce 端的 分 
区 个 数 。 生 成 的 文件 名 格式 为 :“merged_shuffle_shuffleId_bucketId_fileld”， 其 中 的 “merged 
_shuffle_shuffleIld_1 1” 表示 bucketld 为 1， 同时 和 eld 也 为 1。 

在 Mapper 端 ，Task 会 复 用 文件 组 ， 由 于 最 大 并 行 个 数 为 COT， 因 此 文件 组 最 多 分 配 C/ 
T 个 ， 当 某 个 Task 运行 结束 后 会 释放 该 文件 组 ， 之 后 调度 的 Task 则 复 用 前 一 个 Task 所 释放 
的 文件 组 ， 因 此 会 复 用 同一 个 文件 。 最 终 在 该 工作 点 上 生成 的 文件 总 数 为 C/T x R， 如 果 设 
工作 点 个 数 为 E， 则 总 的 文件 数 为 E x CAT x R。 

4. 基于 Hash 的 Shuffle 机 制 的 优 缺 点 

1) 优点 如 下 。 

e 可 以 省 略 不 必要 的 排序 开销 。 

。 避免 了 排序 所 需 的 内 存 开 销 。 

2) 缺点 如 下 。 

e 生成 的 文件 数 过 多 ， 会 对 文件 系统 造成 压力 。 

e 大 量 小 文件 的 随机 读 写 会 带 来 一 定 的 磁盘 开销 。 

e 数据 块 写 入 时 所 需 的 缓存 空间 也 会 随 之 增加 ， 会 对 内 存 造 成 压力 。 
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基于 Hash 的 Shuffle 写 数 据 的 源 代码 解析 


1. 基于 Hash 的 Shuffle 实现 方式 一 的 源 代码 解析 
下 面 继续 针对 Spark 1.6 版 本 中 的 基于 Hash 的 Shuffle 实现 在 数据 写 方面 的 源 代码 进行 





解析 。 在 基于 Hash 的 Shuffle 实现 机 制 中 ， 采 用 HashShuffleWriter 作为 数据 写 人 器。 在 Hash- 





ShuffleWriter 中 控制 Shuffle 写 数据 的 关键 代码 如 下 。 


private| spark | class HashShuffleWriter[ K,V]( 
shuffleBlockResolver: FileShuffleBlockResolver, 
handle: BaseShuffleHandle[ K,V,_|,， 


mapld :Int ， 


context :TaskContext ) 


extends ShuffleWriter[K,V] with Logging | 


// 控 制 每 个 Writer 输出 时 的 切片 个 数 ,对 应 分 区 个 数 
private val dep = handle. dependency 





private val numOutputSplits = dep. partitioner. numPartitions 


/获取 数据 读 写 的 块 管理 


private val blockManager = 





private val ser = Serializer. 


//M FileShuffleBlockResolve 





人 
SparkEnv. get. block Manager 
getSerializer( dep. serializer. getOrElse( null) ) 


r 的 forMapTask 方法 中 获取 指定 的 shuffleld 对 应 的 mapld 


// 对 应 分 区 个 数 所 构建 的 数据 块 写 的 ShuffleWriterGroup 实例 
private val shuffle = shuffleBlockResolver. forMapTask( dep. shuffleld , mapld , numOutputSplits ,ser， 


writeMetrics ) 


/#** Task 输出 时 一 组 记录 的 写 和 人 


*/ 


override def write( records :Iterator[ Product2[K,V]]):Unit = | 


.// 判 断 在 写 时 是 否 需要 先 聚 合 , 即 定义 了 Map 端的 Combine 时 ， 


// 先 对 数据 进行 聚合 再 写 人 。 和 否则 直接 返回 需要 写 人 的 一 批 记录 
val iter = if( dep. aggregator. isDefined ) | 
if( dep. mapSideCombine ) | 


dep. aggregator. get. 
| else | 

records 
| 


| else | 


combineValuesByKey(records ,context ) 
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require( | dep. mapSideCombine," Map — side combine without Aggregator specified!" ) 


records 








// 根 据 分 区 器 ,获取 每 条 记录 对 应 的 bucketId( 即 所 在 的 Reduce 序号 ) ， 
// 根 据 bucketld 从 FileShuffleBlockResolver 构建 的 ShuffleWriterGroup 中 ,获取 
//DiskBlockObjectWriter 实例 ,对 应 磁盘 数据 块 的 数据 写 入 器 


for( elem <— iter) | 





val bucketld = dep. partitioner. getPartition( elem. _1) 


shuffle. writers( bucketId). write( elem. _1 ,elem. _2) 


| 


当 需 要 在 Map 端 进行 聚合 时 ， 使 用 的 是 聚合 句 ( Aggregator ) 的 combineValuesByKey 方法 ， 
在 该 方法 中 使 用 ExternalAppendOnlyMap 类 对 记录 集 进行 处 理 ， 处 理 时 如 果 内 存 不 足 会 引发 


Spil 操作 。 早 期 的 实现 会 直接 缓存 到 内 存 ， 在 数据 量 比 较 大 时 容易 引发 内 存 汇 汤 。 








在 HashShuffleManager 中 ，ShuffleBlockResolver 特质 使 用 的 具体 子 类 为 FileShuffleBlock- 
Resolver ， 即 指定 了 具体 如 何 从 一 个 逻辑 Shuffle 块 标识 信息 来 获取 一 个 块 数据 ， 对 应 为 下 面 
代码 第 7 行 中 的 forMapTask 方法 ， 有 具体 代码 如 下 。 


ee A A 


10. 
业 


je 


/** 
x* 针对 给 定 的 Map Task ,指定 一 个 ShuffleWriterGroup 实例 ,在 数据 块 写 人 器 成 功 
# 关闭 时 会 注册 为 完成 状态 





*/ 

def forMapTask ( shuffleld: Int, mapld :Int, numReduces:Int, serializer: Serializer, 

writeMetrics: ShuffleWriteMetrics) :ShuffleWriterGroup = | 

new ShuffleWriterGroup | 

// 在 FileShuffleBlockResolver 中 维护 着 当前 Map Task 对 应 shuffleld 标识 的 
//Shuffle 中 ,指定 numReduces 个 数 的 Reduce 的 各 个 状态 

shuffleStates. putIfAbsent( shuffleld ,new ShuffleState( numReduces) ) 

private val shuffleState = shuffleStates( shuffleld) 





// 根 据 Reduce 端的 任务 个 数 ,构建 元 素 类 型 为 DiskBlockObjectWriter 的 数组 ， 
// DiskBlockObjectWriter 负责 具体 数据 的 磁盘 写 人 
/原则 上 ,Shuffle 的 输出 可 以 存放 在 各 种 提供 存储 机 制 的 系统 上 ， 
// 但 考虑 到 容错 性 等 方面 ,目前 的 Shuffle 实行 机 制 都 会 写 人 到 磁盘 中 
val writers: Array| DiskBlockObjectWriter | = | 
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2 // 这 里 的 逻辑 Bucket 的 Id 值 即 对 应 的 Reduce 的 任务 序号 ,或 者 说 分 区 ID 

久光 Array. tabulate[ DiskBlockObjectWiriter | (numReduces) | bucketId => 

23.// 针 对 每 个 Map 端 分 区 的 1d 与 Bucket 的 Id 构建 数据 块 的 逻辑 标识 

24. val blockId = ShuffleBlockId ( shuffleld, mapld , bucketld ) O) 
2 val blockFile = block Manager. diskBlock Manager. getFile( blockId ) 

26. val tmp = Utils. tempFileWith( blockF'ile) 

到 从 blockManager. getDisk Writer( blockId ,tmp ,serializerInstance ,bufferSize , writeMetrics ) 
28. | 

20: } 

2 

31. /人 /任务 完成 时 回调 的 释放 写 人 需 方 法 

3 天 override def releaseWriters( success: Boolean) | 

33. shuffleState. completedMapTasks. add( mapId ) 

34. } 

25, } 

36. } 


其 中 ，ShuffleBlockId 实例 构建 的 源 代码 如 下 。 


1. case class ShuffleBlockId( shuffleld:Int,mapld:Int,reduceld:Int)extends BlockId | 
2 override def name:String = " shuffle_" + shuffleld +"_" +mapld +"_" +reduceld 
S00 





从 name 方法 的 重 载 上 可 以 看 出 后 续 构建 的 文件 与 代码 中 的 mapId 、reduceld 的 关系 。 当 
然 ， 同一 个 Shuffle 的 所 有 输出 数据 块 都 会 带 上 shuffleld 这 个 唯一 标识 的 ， 因 此 从 全 局 角度 
上 看 ,逻辑 数 据 块 name 不 会 重复 (针对 一 些 推测 机 制 或 失败 重 试 机 制 之 类 的 场景 ， 人 逻辑 
name 没有 带 上 时 间 信 息 ， 因 此 缺少 多 次 执行 的 输出 区 别 ， 但 在 管理 这 些 信 息 时 会 维护 一 个 
时 间作 为 有 效 性 判断 ) 。 

2. 基于 Hash 的 Shuffle 实现 方式 二 的 源 代码 解析 

下 面 通过 详细 解析 FileShuffleBlockResolver 源 代 码 来 加 深 对 文件 合并 机 制 的 理解 。 

由 于 在 Spark 1. 6 中 ， 文 件 合 并 机 制 已 经 被 删除 ， 因 此 下 面 基于 Spark 1.5 版 本 的 代码 对 
文件 合并 机 制 的 具体 实现 细节 进行 解析 ， 以 下 代码 位 于 FileShuffleBlockResolver 类 中 。 

合并 机 制 的 关键 控制 代码 如 下 。 





























/ ** 
* 获取 一 个 针对 特定 Map Task 的 ShuffleWriterGroup 


* when the writers are closed successfully 
*/ 
def forMapTask ( shuffleld : Int, mapld :Int, numBuckets: Int , serializer : Serializer, 
writeMetrics :ShuffleWriteMetrics ) :ShuffleWriterGroup = | 
newShuffleWriterGroup | 


Co 5 








46. 
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val writers: Array| DiskBlockObjectWriter | = if( consolidateShuffleFiles ) | 











. // 获 取 未 使 用 的 文件 组 








fileGroup = getUnusedFileGroup( ) 
Array. tabulate[ DiskBlockObjectWriter | (numBuckets ) | bucketId => 
val blockId = ShuffleBlockId( shuffleId ,mapId , bucketld ) 
// 注 意 获取 磁盘 写 人 器 时 ,传人 的 第 二 个 参数 与 未 使 用 文件 合并 机 制 时 的 差异 
//fileGroup( bucketld) :构造 需 方 式 调用 ,对 应 到 apply 的 方法 调用 
blockManager. getDisk Writer ( blockId , fileGroup ( bucketId ) , serializerInstance, buffer- 


























Size ， 
writeMetrics ) 
| 
| else | 
Array. tabulate[ DiskBlockObjectWriter | (numBuckets) | bucketId => 
val blockId = ShuffleBlockId( shuffleId ,mapId , bucketld ) 





. // 根 据 ShuffleBlockId 信息 获取 文件 名 


val blockFile = block Manager. diskBlock Manager. getFile( blockld) 
val tmp = Utils. tempFileWith( blockFile) 
block Manager. getDisk Writer( blockId ,tmp , serializerInstance , bufferSize ,writeMetrics ) 


writeMetrics. incShuffleWriteTime( System. nanoTime - openStartTime ) 


override def releaseWriters( success: Boolean ) | 


. // 带 文件 合并 机 制 时 , 写 和 人 器 在 释放 后 的 处 理 
. //3 个 关键 信息 ;mapld .offsets 和 lengths 





if( consolidateShuffleFiles ) | 
if( success) | 
val offsets = writers. map( _. fileSegment( ). offset) 
val lengths = writers. map( _. fileSegment( ). length) 


fileGroup. recordMapOutput( mapId ,offsets , lengths ) 
| 


. // 回 收文 件 组 ,便于 后 续 复 用 


recycleFileGroup( fileGroup) 
| else | 
shuffleState. completedMapTasks. add ( mapld ) 


i 





其 中 ,第 10 行 中 的 consolidateShuffleFiles 变量 用 于 判断 是 否 设置 了 文件 合并 机 制 ， 当 设 
置 consolidateShuffleFiles 为 true 后 ， 会 继续 调用 getUnusedFileGroup 方法 ， 在 该 方法 中 会 获取 
未 使 用 的 文件 组 ， 即 重新 分 配 或 已 经 释放 可 以 复 用 的 文件 组 。 
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获取 未 使 用 的 文件 组 (ShuffleFileGroup ) 的 相关 代码 getUnusedFileGroup 如 下 。 


SN Cl lh 


P= 
| 


2 


private def getUnusedFileGroup( ) :ShuffleFileGroup = | 
// 获 取 已 经 构建 但 未 使 用 的 文件 组 ,如 果 获 取 失 败 , 则 重新 构建 一 个 文件 组 
val fileGroup = shuffleState. unusedFileCroups. poll( ) © 























if(fileGroup |! = null)fileGroup else newFileGroup( ) 
| 
// 重 新 构建 一 个 文件 组 的 源 代码 
private def newFileGroup( ) :ShuffleFileGroup = | 
// 构 建 后 会 对 文件 编号 进行 递增 ,该 文件 编号 最 终 用 于 生成 的 文件 名 中 


val fileld = shuffleState. nextFileId. getAndIncrement( ) 











val files = Array. tabulate[ File | (numBuckets) | bucketId => 


. // 最 终 的 文件 名 ,可 以 通过 文件 名 的 组 成 及 取 值 细 方 ， 





// 加 深 对 实现 细节 在 文件 个 数 上 的 差异 的 理解 
val filename = physicalFileName ( shuffleld ,bucketld , fileld ) 
block Manager. diskBlock Manager. getFile( filename) 
| 
// 构 建 并 添加 到 shuffleState 中 ,便于 后 续 复 用 
val fileGroup = new ShuffleFileGroup( shuffleld ,fileld ,files) 
shuffleState. allFileGroups. add(fileCroup ) 
fileGroup 


| 


其 中 ， 第 13 行 代码 对 应 为 生成 的 文件 名 ， 即 物理 文件 名 ， 相 关 代码 如 下 。 


2. 
3 


private def physicalFileName( shuffleld: Int, bucketld :Int, fileld:Int) = | 
"merged_shuffle % d_% d_%d". format( shuffleld, bucketld ,fileld) 
| 





可 以 看 到 ， 与 未 使 用 文件 合并 时 的 基于 Hash 的 Shuffle 实现 方式 不 同 的 是 ， 在 生成 的 文 
件 名 中 没有 对 应 的 mapId， 取 而 代 之 的 是 与 文件 组 相关 的 fleIld， 而 fleId 则 是 多 个 Mapper 端 
的 Task 所 共用 的 ， 在 此 仅仅 从 生成 的 物理 文件 名 中 也 可 以 看 出 文件 合并 的 某 些 实现 细节。 

另外 ， 对 应 生成 的 文件 组 既然 是 复 用 的 ， 当 一 个 Mapper 端的 Task 执行 结束 后 便 会 释放 
该 文件 组 (ShuffleFileGroup) ， 之 后 继续 调度 时 便 会 复 用 该 文件 组 。 相 应 的 ， 调 度 到 某 个 Ex- 
ecutor 工作 点 上 同时 运行 的 Task 最 大 个 数 ， 就 对 应 了 最 多 分 配 的 文件 组 个 数 。 

而 在 TaskSchedulerImpl 调度 Task 时 ， 各 个 Executor 工作 点 上 Task 调度 控制 的 源 代码 说 
明了 在 各 个 Executor 工作 点 上 调度 并 行 的 Task 数 ， 具 体 代 码 如 下 。 


1 
2 
3 
4 








private def resourceOfferSingleTaskSet( 
taskSet: TaskSetManager， 
maxLocality : TaskLocality, 
shuffledOffers :Seq[ WorkerOffer ] ， 
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availableCpus : Array[ Int ] ， 


tasks:Seq[ ArrayBuffer[ TaskDescription | | ) :Boolean = | 


for(i<-0 until shuffledOffers. size ) | 

val execld = shuffledOffers (i). executorld 
10. val host = shuffledOffers(i). host 
11.// 判 断 当 前 Executor 工作 点 上 可 用 的 内 核 个 数 是 否 满 足 Task 所 需 的 内 核 个 数 
12. //CPUS_PER_TASK :表示 设置 的 每 个 Task 所 需 的 内 核 个 数 
13. if(availableCpus(i) > = CPUS_PER_TASK)!| 
14. try| 
15. for(task <— taskSet. resourceOffer( execld, host, maxLocality ) ) | 


5 
6 
7. var launchedTask = false 
8 
9 























jk launchedTask = true 
19. lcatch | 


21. | 

22. | 

2 | 

24. returnlaunchedTask 
2S00 


其 中 ,设置 每 个 Task 所 需 的 内 核 个 数 的 配置 属性 如 下 。 


1l. // CPUs to request per task 
2. val CPUS_PER_TASK = conf getInt( "spark. task. cpus" ,1) 


对 于 这 些 会 影响 Executor 中 并 行 执行 的 任务 数 的 配置 信息 ， 在 设置 时 需要 多 方面 的 考 
虑 ， 包 括 内 核 个 数 与 任务 个 数 的 合适 比例 ， 以 及 在 内 存 模 型 中 为 任务 分 配 内 存 的 具体 策略 
等 。 任 务 分 配 内 存 的 具体 策略 可 以 参考 Spark 官方 给 出 的 具体 设计 文档 ， 以 及 文档 中 各 种 设 
计 方 式 的 权衡 等 内 容 。 





基于 Sort 的 Shuffle 





由 于 最 初 在 Spark 中 为 了 避免 不 必要 的 排序 开销 而 使 用 的 基于 Hash 的 Shuffle 实现 机 制 
中 存在 一 定 的 缺陷 ,在 超大 规模 数据 集 的 场景 下 会 造成 一 定 的 性 能 瓶颈 ， 对 应 的 优化 措施 ， 
即 在 Spark 0. 8. 1 引入 的 File Consolidation 也 只 是 在 一 定 程 度 上 缓解 了 该 问题 ， 并 没有 彻底 解 
决 。 因 此 在 SparkSpark 1. 1. 0 版 本 中 ,借鉴 Hadoop 的 实现 方式 ， 引 入 了 基于 Sort 的 Shuffle 
实现 机 制 。 

基于 Sort 的 Shuffle 实现 机 制 在 Spark 1.1.0 版 本 中 被 引进 后 ， 在 Spark 1. 2 版 本 开始 替 
换 基 于 Hash 的 Shuffle 实现 机 制 ， 将 基于 Sort 的 Shuffle 实现 机 制 设置 为 默认 方式 。 即 将 配置 
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属性 “spark. shuffle. manager” 从 hash 换 成 了 sort， 对 应 ShuffleManager 的 实现 类 分 别 是 
HashShuffleManager 和 SortShuffleManager。 

在 Spark 1. 1 版 本 中 ，Spark 借鉴 了 Hadoop MapReduce 的 基于 Sort 的 Shuffle 过 程 ， 不 再 
为 每 个 Reduce 端的 Task 生成 一 个 文件 ， 而 是 根据 分 区 ID 进行 排序 ， 然 后 输出 到 单个 数据 
文件 中 ， 并 且 同 时 生成 对 应 的 索引 文件 。 在 Reduce 端 获 取 数 据 时 ， 会 根据 该 索引 文件 从 数 
据 文件 中 获取 它 所 需要 的 数据 。 因 此 在 基于 Sort 的 Shuffle 过 程 中 ， 可 以 避免 基于 Hash 的 
Shuffle 实现 机 制 的 缺陷 ， 更 有 利于 超大 规模 数据 集 的 处 理 。 


基于 Sort 的 Shuffle 内 核 ) 


Sorted Based Shuffle， 即 基于 Sorted 的 Shuffle 实现 机 制 ， 在 该 Shuffle 过 程 中 ，Sorted 体 
现在 输出 的 数据 会 根据 目标 的 分 区 Id ( 即 带 Shuffle 过 程 的 目标 RDD 中 各 个 分 区 的 Id 值 ) 
进行 排序 ， 然 后 写 人 一 个 单独 的 Map 端 输出 文件 中 。 相 应 的 ， 各 个 分 区 内 部 的 数据 并 不 会 
再 根据 Key 值 进行 排序 ， 除 非 调用 带 排 序 目 的 的 方法 ， 在 方法 中 指定 Key 值 的 Ordering 实 
例 ， 才 会 在 分 区 内 部 根据 该 Ordering 实例 对 数据 进行 排序 。 当 Map 端的 输出 数据 超过 内 存 
容纳 大 小 时 ， 会 将 各 个 排序 结果 Spill 到 磁盘 上 ， 最 后 再 将 这 些 Spil 的 文件 合并 到 一 个 最 终 
的 文件 中 。 在 Spark 的 各 种 计算 算 子 中 到 处 都 体现 了 一 种 惰性 的 理念 ， 在 此 也 是 类 似 ， 在 提 
升 性 能 需要 时 ， 引 入 根据 分 区 Id 排序 的 设计 ， 同 时 仅 在 指定 分 区 内 部 排序 的 情况 下 才 会 进 
行 全 局 排序 。 而 相 比 之 下 ， Hadoop 的 MapReduce 则 带 有 一 定 的 学 术 和 气息 ， 中 规 中 和 矩 ， 严 格 
设计 Shuffle 阶段 中 的 各 个 步骤 。 

基于 Hash 的 Shuffle 实现 ，ShuffleManager 的 具体 实现 子 类 为 HashShuffleManager， 对 应 
的 具体 实现 机 制 如 图 7-6 所 示 。 
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图 7-6 基于 Sorted 的 Shuffle 实现 机 制 的 框架 类 图 
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在 图 7-6 中 ， 各 个 不 同 的 ShuffleHandle 与 不 同 的 具体 Shuffle 写 人 器 实现 子 类 是 一 一 对 
应 的 ， 可 以 认为 是 通过 注册 时 生成 的 不 同 ShuffleHandle 设置 不 同 的 Shuffle 写 人 器 实 现 子 类 。 

从 ShuffleManager 注册 的 配置 属性 与 具体 实现 子 类 的 映射 关系 ， 即 前 面 提 及 的 在 Spark- 
Env 中 实例 化 的 代码 ， 可 以 看 出 " sort" 与 " tungsten - sort" 对 应 的 具体 实现 子 类 都 
是 "org. apache. spark. shuffle. sort. SortShuffleManager" 。 也 就 是 当前 基于 Sort 的 Shuffle 实现 机 
制 与 使 用 Tungsten 项 目的 Shuffle 实现 机 制 都 是 通过 SortShuffleManager 类 来 提供 接口 ， 两 种 
实现 机 制 的 区 别 在 于 该 类 中 使 用 了 不 同 的 Shuffle 数据 写 和 人 顺 。 

SortShuffleManager 根据 内 部 采用 的 不 同 实现 细节 ， 对 应 有 两 种 不 同 的 构建 Map 端 文件 输 
出 的 写 方式 (详细 信息 可 以 进一步 参考 SortShuffleManager 的 类 注释 ) ， 分 别 为 序列 化 排序 模 
式 与 反 序 列 化 排序 模式 。 

1) 序列 化 排序 (Serialized sorting ) 模式 : 这 种 方式 对 应 新 引入 的 基于 Tungsten 项 目的 
方式 。 

2) 反 序 列 化 排序 (Deserialized sorting) 模 式 : 这 种 方式 对 应 除了 前 面 这 种 方式 之 外 的 其 
他 方式 。 

基于 Sort 的 Shuffle 实现 机 制 采用 的 是 反 序 列 化 排序 (Deserialized sorting ) 模式 ， 下 面 分 
析 该 实现 机 制 下 的 数据 写 入 器 的 实现 细节 。 

在 图 7-6 中 可 以 看 到 ， 基 于 Sort 的 Shuffle 实现 机 制 ， 有 具体 的 写 人 器 的 选择 与 注册 得 到 
的 ShuffleHandle 类 型 有 关 ， 参 考 SortShuffleManager 类 的 registerShuffle 方法 ， 相 关 代 码 如 下 。 











1 override def registerShuffle[ K,V,C]( 

多 shuffleld : Int, 

3 numMaps: Int, 

4 dependency:ShuffleDependency[K,V,C] ) :ShuffleHandle = | 

SS // 通 过 shouldBypassMergeSort 方法 判断 是 否 满足 回 退 到 Hash 风格 的 Shuffle 条 件 
6 

Y 

8 

9 





if( SortShuffleWriter shouldBypassMergeSort( SparkEnv. get. conf, dependency) ) | 

// 如 果 当 前 的 分 区 个 数 小 于 设置 的 配置 属性 : 

// spark. shuffle. sort. bypassMergeThreshold ,同时 不 需要 在 Map 对 数据 进行 聚合 ， 
// 此 时 可 以 直接 写 文件 ,并 在 最 后 将 文件 合并 




















10. // 

11. 24 

12. // This avoids doing serialization anddeserialization twice 

13. // to merge together the spilled files, which would happen with the normal code path. 
14. // The downside is having multiple files open at a time and thus more memory 
15. //allocated to buffers. 

16. new BypassMergeSortShuffleHandle [ K,V |]( 

7 shuffleId ,numMaps ,dependency. asInstanceOf[ ShuffleDependency[ K,V,V]]) 
18. | else if( SortShuffleManager. canUseSerializedShuffle( dependency ) ) | 

19. 2 

20. | else | 


2 // Otherwise, buffer map outputs in adeserialized form: 
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2 new BaseShuffleHandle (shuffleId ,numMaps ,dependency) 
23. | 
24. | 


© 


车手 Sort 的 Shuffle 写 





本 数据 的 源 代码 解析  ) 


A 





基于 Sort 的 Shuffle 实现 机 制 中 相关 的 ShuffleHandle 包含 BypassMergeSortShuffleHandle 与 
BaseShuffleHandle。 对 应 这 两 种 ShuffleHandle 及 其 相关 的 Shuffle 数据 写 人 需 类 型 的 相关 代码 
可 以 参考 SortShuffleManager 类 的 getWriter 方法 ， 关 键 代码 如 下 。 





1 / ** Get a writer for a given partition. Called on executors by map tasks. */ 

多 override def getWriter[ K,V]( 

3 handle: ShuffleHandle, 

4 mapId: Int, 

3 context :TaskContext) :ShuffleWriter[ K,V | = | 

6 numMapsForShuffle. putIfAbsent( 

7 handle. shuffleld ,handle. asInstanceOf| BaseShuffleHandle[ _,_,_| ]. numMaps) 

8 val env = SparkEnv. get 

9 // 通 过 对 ShuffleHandle 类 型 的 模式 匹配 ,构建 具体 的 数据 写 人 需 

10. handle match | 

11. 

12: case bypassMergeSortHandle: BypassMergeSortShuffleHandle [ K @ unchecked,V @ un- 
checked| => 

13. new BypassMergeSortShuffleWriter( 

14. env. blockManager， 

15. shuffleBlockResolver. asInstanceOf[ IndexShuffleBlockResolver | ， 

16. bypassMergeSortHandle, 

17. mapld, 

18. context, 

19. env. conf) 

20. case other: BaseShuffleHandle| K @ unchecked,V @unchecked,_| => 

之 下 new SortShuffleWriter( shuffleBlockResolver ,other,mapId ,context) 

22. } 

23. 1 


在 对 应 构建 的 两 种 数据 写 人 器 类 BypassMergeSortShuffleWriter 与 SortShuffleWriter 中 ， 都 
是 通过 变量 shuffleBlockResolver 对 逻辑 数据 块 和 物理 数据 块 的 映射 进行 解析 ， 而 该 变量 使 用 
的 是 与 基于 Hash 的 Shuffle 实现 机 制 不 同 的 解析 类 ， 即 当前 使 用 IndexShuffleBlockResolver。 

下 面 开始 解析 这 两 种 写 数据 块 方式 的 源 代码 实现 。 

1. BypassMergeSortShuffleWriter 写 数 据 的 源 代码 解析 

BypassMergeSortShuffleWriter 类 实现 了 带 Hash 风格 的 基于 Sort 的 Shuffle 机 制 ， 为 每 个 
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Reduce 端的 任务 构建 一 个 输出 文件 ， 将 输入 的 每 条 记录 分 别 写 人 各 自 对 应 的 文件 中 ， 并 在 
最 后 将 这 些 基 于 各 个 分 区 的 文件 合并 成 一 个 输出 文件 。 
从 前 面 提 到 的 实例 中 可 以 知道 ， 在 Rueducer 端 任务 数 比 较 少 的 情况 下 ， 基 于 Hash 的 








Shuffle 实现 机 制 明显 比 基 于 Sort 的 Shuffle 实现 机 制 要 快 ， 因 此 基于 Sort 的 Shuffle 实现 机 制 
提供 了 一 个 fallback 方案 ， 当 Rueducer 端 任务 数 少 于 配置 属性 “spark. shuffle. sort. bypass- 
MergeThreshold” 设 置 的 个 数 时 ， 使 用 带 Hash 风格 的 fallback 计划 ， 由 BypassMergeSortShuf- 
fleWriter 具体 实现 。 

使 用 该 写 人 器 的 条 件 如 下 。 

1) 不 能 指定 Ordering， 从 前 面 数据 读 取 需 的 解析 可 以 知道 ， 当 指定 Ordering 时 ， 会 对 
分 区 内 部 的 数据 进行 排序 。 因 此 ， 对 应 的 BypassMergeSortShuffleWriter 写 入 器 避免 了 排序 
开销 。 

2) 不 能 指定 聚合 器 (Aggregator) 。 

3) 分 区 个 数 小 于 “spark. shuffle. sort. bypassMergeThreshold” 配置 属性 指定 的 个 数 。 

和 其 他 ShuffleWriter 的 具体 子 类 一 样 ，BypassMergeSortShuffleWriter 写 数据 的 具体 实现 位 
于 实现 的 write 方法 中 ， 关 键 代码 如 下 。 





























public void write( Iterator < Product2 < K,V >> records )throws IOException | 
// 为 每 个 Reduce 端的 分 区 打开 的 DiskBlockObjectWriter 存放 于 partitionWriters ， 
// 需 要 根据 具体 Reduce 端的 分 区 个 数 进行 构建 








1 

之 

3 

4 assert( partitionW riters == null ) ; 

Sa if( | records. hasNext( ) ) | 

6 partitionLengths = new long[ numPartitions ] ; 

7 // 初 始 化 索引 文件 的 内 容 , 此 时 对 应 各 个 分 区 的 数据 量 或 偏 移 量 需要 在 后 续 

8 /获取 分 区 的 真实 数据 量 时 重 写 

9. shuffleBlock Resolver. writeIndexFileAndCommit( shuffleId ,mapId ,partitionLengths ,null) ; 
10. // 下 面 代 人 码 的 调用 形式 是 对 应 在 Java 类 中 调用 Scala 提供 的 object 中 的 




































































11. //apply 方法 的 形式 ,这 是 由 编译 器 编译 Scala 中 的 object 得 到 的 结果 来 决定 的 

下 mapStatus = MapStatus$. MODULE $. apply ( block Manager. shuffleServerld ( ) , partition- 
Lengths ) ; 

13. return ; 

14. } 

|S final SerializerInstance serInstance = serializer. newInstance( ) ; 

10. final longopenStartTime = System. nanoTime( ) ; 

17. // 对 应 每 个 分 区 各 配置 一 个 磁盘 写 人 器 DiskBlockObjectWriter 

18. partitionWriters = new DiskBlockObjectWriter| numPartitions | ; 

19. // 注 意 ,在 该 写 入 方式 下 ,会 同时 打开 numPartitions 个 DiskBlockObjectWriter， 

20. // 因 此 对 应 的 分 区 数 不 应 设置 得 过 大 ,避免 带 来 过 重 的 内 存 开 销 。 

2 // 目 前 对 应 DiskBlockObjectWriter 的 缓存 大 小 默认 配置 为 32K， 

现 // 比 早先 的 100 降低 了 很 多 ， 

23. // 但 也 说 明 不 适合 同时 打开 太 多 的 DiskBlockOpjectWriter 实例 


24. for(int i1=0; i< numPartitions; 1 ++ ) | 








54. 
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final Tuple2 < TempShuffleBlockId ,File > tempShuffleBlockIdPlusFile = 
blockManager. diskBlockManager( ). createTempShuffleBlock( ) ; 
final File file =tempShuffleBlockIdPlusFile. 2() ; 
finalBlockId blockId =tempShuffleBlockIdPlusFile. _1( ); O) 
partitionWriters[ i] = 
blockManager. getDiskW riter ( blockld, file, serInstance, fileBufferSize, writeMetrics ) 
. open( ) ; 


| 


// 读 取 每 条 记录 ,并 根据 分 区 器 将 该 记录 交 由 分 区 对 应 的 DiskBlockObjectWriter， 
// 写 入 各 自 对 应 的 临时 文件 中 
while( records. hasNext( ) ) | 
final Product2 <K,V > record = records. next( ) ; 
final K key = record. _1( ); 
partitionWriters| partitioner. getPartition( key) ]. write( key, record. 2()); 


// 获 取 最 终 合 并 后 的 文件 名 ,对 应 格式 为 : 

//" shuffle_" +shuffleId +"_" +mapld +"_" +reduceld +".index" ,并 且 其 中 的 reduceld 

// 为 0, 对 应 的 含义 就 是 该 文件 包含 所 有 为 Reduce 端 输 出 的 数据 

File output = shuffleBlockResolver. getDataFile( shuffleld, mapld ) ; 

Filetmp = Utils. tempFileWith( output ) ; 

// 在 此 合并 前 面 生成 的 各 个 中 间 临 时 文件 ,并 获取 各 个 分 区 对 应 的 数据 量 ， 

// 由 数据 量 可 以 得 到 对 应 的 偏 移 量 

partitionLengths = writePartitionedFile(tmp ) ; 

// 主 要 是 根据 前 面 获 取 的 数据 量 , 重 写 Index 文件 中 的 偏 移 量 信息 

shuffleBlockResolver. writeIndexFileAndCommit( shuffleId ,mapId ,partitionLengths ,tmp ) ; 

// 封 装 并 返回 任务 结果 
mapStatus = MapStatus $. MODULE $. apply ( block Manager. shuffleServerld ( ), partition- 
Lengths ) ; 

| 














思 


























其 中 第 26 行 代码 ， 描 述 了 各 个 分 区 所 生成 的 中 间 临 时 文件 的 格式 与 对 应 的 Block1d， 具 


体 代码 如 下 。 


/ ** Produces a unique block id and File suitable for storing shuffled intermediate results. */ 
/** 中 间 临 时 文件 名 的 格式 由 前 级 temp_shuffle_ 与 randomUUID 组 成 ,可 以 唯一 标识 一 个 
BlockId * / 

def createTempShuffleBlock( ) : (TempShuffleBlockId ,File) = | 

var blockId = new TempShuffleBlockId( UUID. randomUUID( ) ) 
while( getFile(blockId). exists( ) ) | 
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blockId = new TempShuffleBlockId( UUID. randomUUID( ) ) 


| 
(blockId ,getFile(blockId) ) 


| 


NO 





从 上 面 的 分 析 可 以 知道 ， 每 个 Map 端的 任务 最 终 会 生成 两 个 文件 : 数据 (Data) 文件 
和 索引 (Index) 文件 。 

另外 在 使 用 DiskBlockObjectWriter 写 记 录 时 ， 是 以 32 条 记录 批 次 写 人 的 ， 不 会 占用 太 大 
的 内 存 。 但 由 于 不 能 指定 聚合 需 (Aggregator) ， 写 数据 时 也 是 直接 写 人 记录 ， 因 此 对 应 后 续 
的 网 络 VO 的 开销 也 会 很 大 。 

2. SortShuffleWriter 写 数 据 的 源 代码 解析 

前 面 BypassMergeSortShuffleWriter 的 写 数据 是 在 Reduce 端的 分 区 个 数 较 少 的 情况 下 提供 
的 一 种 优化 方式 ， 但 当 数 据 集 规 模 非 常 大 ， 使 用 该 写 数据 方式 不 合适 时 ， 就 需要 使 用 
SortShuffleWriter 来 写 数 据 块 。 

和 其 他 ShuffleWriter 的 具体 子 类 一 样 ，SortShuffleWriter 写 数据 的 具体 实现 位 于 实现 的 
write 方法 中 ， 关 键 代 码 如 下 。 















































1 override def write( records :Iterator| Product2[K,V]]):Unit = | 

2 // 当 需要 在 Map 端 进行 聚合 操作 时 ,此 时 会 将 指定 的 聚合 器 ( Aggregator) 

3. /与 Key 值 的 Ordering 传人 到 外 部 排序 器 ExternalSorter 中 

4 sorter = if( dep. mapSideCombine ) | 

人 require( dep. aggregator. isDefined," Map — side combine without Aggregator specified!" ) 
6 new ExternalSorter[ K,V,C]( 

区 context ,dep. aggregator ,Some( dep. partitioner ) ,dep. keyOrdering ,dep. serializer) 

8 | else | 

9 // 没 有 指定 Map 端 使 用 聚合 时 ,传人 ExternalSorter 的 聚合 器 ( Aggregator) 

10. // 与 Key 值 的 Ordering 都 设 为 None, 即 不 需要 传人 ,对 应 在 Reduce 端 读 取 数 据 

11. // 时 才 根 据 聚 合 器 分 区 数据 进行 聚合 ,并 根据 是 否 设 置 Ordering 而 选择 是 否 对 
12. /分 区 数据 进行 排序 

13. // In this case we pass neither an aggregator nor an ordering to the sorter, because we 
14. // don t care whether the keys get sorted in each partition; that will be done on the 
sy // reduce side if the operation being run issortByKey. 

16. new ExternalSorter[ K,V,V]( 

WR context, aggregator = None, Some( dep. partitioner) , ordering = None , dep. serializer) 
18. | 

19，/ 将 写 人 的 记录 集 全 部 放 入 外 部 排序 器 

20. sorter. insertAll( records ) 

Zl: 

2 // Don tbother including the time to open the merged output file in the shuffle write time, 
2 // because it just opens a single file ,so is typically too fast to measure accurately 

24. //(see SPARK -3570 ). 





25. // 和 BypassMergeSortShuffleWriter 一 样 ,获取 输出 文件 名 和 BlockId 





20. 
Je 
28. 


2 
30. 
3 
3 
3 有 
34. 
35. 
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val output = shuffleBlock Resolver. getDataFile( dep. shuffleId ,mapId ) 

val tmp = Utils. tempFileWith( output ) 

val blockId = ShuffleBlockId ( dep. shuffleld, mapId, IndexShuffleBlockResolver. NOOP_ RE- 
DUCE_ID) O) 
// 将 分 区 数据 写 入 文件 ,返回 各 个 分 区 对 应 的 数据 量 


val partitionLengths = sorter. writePartitionedFile( blockId ,tmp) 

















// 和 BypassMergeSortShuffleWriter 一 样 ,更 新 索引 文件 的 偏 移 量 信 息 
shuffleBlockResolver. writeIndexFileAndCommit( dep. shuffleld ,mapId , partitionLengths , tmp ) 
mapStatus = MapStatus( block Manager. shuffleServerld , partitionLengths ) 


| 


这 种 基于 Sort 的 Shuffle 实现 机 制 中 引入 了 外 部 排序 器 (ExternalSorter) ，ExternalSorter 继 
承 了 Spilable， 因 此 内 存 使 用 在 达到 一 定 疹 值 时 ， 会 Spil 到 磁盘 ， 可 以 减少 内 存 带 来 的 


开销 。 








通过 查看 外 部 排序 器 (ExternalSorter) 的 insertAll 方法 ， 对 应 调用 在 第 20 行 ， 该 方法 内 部 




















在 处 理 完 〈 包 含 聚 合 和 非 聚 合 两 种 方式 ) 每 一 条 记录 时 ， 都 会 检查 是 否 需 要 Spill。 如 果 内 
部 各 种 细节 比较 多 ， 这 里 以 Spill 条 件 判断 为 主线 ， 简 单 描述 与 条 件 相关 的 代码 。 有 具体 判断 











是 否 需要 Spill 的 相关 代码 ， 可 以 参考 Spillable 类 中 的 maybeSpill 方法 (该 方法 简单 的 调用 流 
程 为 : ExternalSorter #insterAll 一 >ExternalSorter #maybeSpillCollection 一 Spillable#maybeSpill ) ， 


关键 代码 如 下 。 


protected def maybeSpill( collection:C,currentMemory: Long) :Boolean = | 
// 判 断 是 否 需 要 Spill 
var shouldSpill = false 
]/ 1. 检查 当前 记录 数 是 否 是 32 的 倍数 , 即 对 小 批量 的 记录 集 进 行 Spill 
// 2. 同时 ,当前 需要 的 内 存 大 小 是 否 达到 或 超过 了 当前 分 配 的 内 存 浆 值 
if(elementsRead % 32 ==0 && currentMemory > =myMemoryThreshold) | 











// Claim up to double our current memory from the shuffle memory pool 
val amountToRequest =2 * currentMemory - myMemoryThreshold 
// 实 际 上 会 先 申请 内 存 , 然 后 再 次 判断 ,再 决定 是 否 Spill 


val granted = 























taskMemory Manager. acquireExecutionMemory ( amountToRequest, MemoryMode. ON _ 
HEAP , null) 
myMemoryThreshold + = granted 
// I{f we were granted too little memory to grow further( eithertryToAcquire returned 0 ， 
// or we already had more memory thanmyMemoryThreshold ) , spill the current collection 
shouldSpill = currentMemory > =myMemoryThreshold 
| 
// 当 满足 下 列 条 件 之 一 时 ,需要 Spil ,条 件 如 下 。 
/A 1. 当前 面 判断 结果 为 true 时 
上 2. 从 上 次 Spil 之 后 所 读 取 的 记录 数 超过 配置 的 阔 值 时 
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20. // 配 置 属性 为 :" spark. shuffle. spill. numElementsForceSpillThreshold" 
2il shouldSpill = shouldSpill | | _elementsRead > numElementsForceSpillThreshold 
2 // Actually spill 

238 if( shouldSpill) | 

24. _spillCount + =1 

23: logSpillage( currentMemory) 

26. spill( collection ) 

27: _elementsRead =0 

28. _memoryBytesSpilled + = currentMemory 

29. releaseMemory( ) 

30. } 

31. shouldSpill 

32 } 


对 于 外 部 排序 器 ( ExternalSorter) ， 除 了 insertAll 方法 外 ， 它 的 writePartitionedFile 方法 
也 非常 重要 。 该 方法 的 代码 如 下 。 





1. def writePartitionedFile( 
2 blockId :BlockId ， 
3 outputFile:File) :; Array[ Long | = | 








其 中 ，BlockId 是 数据 块 的 逻辑 位 置 ，File 参数 则 是 对 应 逻辑 位 置 的 物理 存储 位 置 。 
这 两 个 参数 值 的 获取 方法 和 使 用 BypassMergeSortShuffleHandle 及 其 对 应 ShuffleWriter 是 
一 样 的 。 

在 该 方法 中 ， 有 一 个 容易 混淆 的 地 方 ， 与 Shuffle 的 度量 (Metric) 信息 有 关 ， 相 应 的 代 
码 如 下 。 





1. context. taskMetrics( ). incMemoryBytesSpilled( memoryBytesSpilled ) 
2. context. taskMetrics( ). incDiskBytesSpilled( diskBytesSpilled ) 


其 中 ,第 1 行 对 应 修改 了 Spilled 的 数据 在 内 存 中 的 字 节 大 小 ， 第 2 行 则 对 应 修改 了 
Spilled 的 数据 在 磁盘 中 的 字 节 大 小 。 在 内 存 中 时 ， 数 据 是 反 序列 化 形式 存放 的 ， 而 存储 到 磁 
盘 (默认 会 序列 化 ) 时 ， 会 对 数据 进行 序列 化 。 反 序列 化 后 的 数据 会 远 远 大 于 序列 化 后 的 
数据 (也 可 以 通过 UI 界面 查看 这 两 个 度量 信息 的 大 小 差异 来 确认 ， 有 具体 差异 的 大 小 和 数据 
与 选择 的 序列 化 器 有 关 ， 有 兴趣 的 读者 可 以 参考 各 序列 右 间 的 性 能 等 比较 文档 ) 。 

从 这 一 点 也 可 以 看 出 ， 如 果 在 内 存 中 使 用 反 序 列 化 的 数据 ， 会 大 大 增加 内 存 的 开销 
(也 意味 着 增加 GC 负载 ) ， 并 且 反 序列 化 也 会 增加 CPU 的 开销 ， 因 此 引入 了 利用 Tungsten 
项 目的 基于 Tungsten Sort 的 Shuffle 实现 机 制 ，Tungsten 项 目的 优化 主要 有 3 个 方面 ， 这 里 从 
避免 反 序列 化 的 数据 量 会 极 大 地 消耗 内 存 这 点 考虑 ， 主 要 是 借助 Tungsten 项 目的 内 存 管理 模 
型 ， 可 以 直接 处 理 序列 化 的 数据 ; 同时 在 CPU 开销 方面 ， 直 接 处 理 序列 化 数据 ， 可 以 避免 
数据 反 序 列 化 的 这 部 分 处 理 开 销 。 
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基于 Tungsten Sort 的 Shuffle 





基于 Tungsten Sort 的 Shuffle 实现 机 制 主要 是 借助 Tungsten 项 目 所 做 的 优化 来 高 效 处 理 
Shuffle。 

Spark 提供 了 配置 属性 ， 用 于 选择 具体 的 Shuffle 实现 机 制 ， 但 需要 说 明 的 是 ， 虽 然 默认 
情况 下 ，Spark 默认 开启 的 是 基于 Sort 的 Shuffle 实现 机 制 (对 应 spark. shuffle. manager 的 默 
认 值 ) ， 但 实际 上 ， 参 考 Shuffle 的 框架 内 核 部 分 可 知 ， 基 于 Sort 的 Shuffle 实现 机 制 与 基于 
Tungsten Sort 的 Shuffle 实现 机 制 都 是 使 用 SortShuffleManager， 而 内 部 使 用 的 具体 实现 机 制 是 
通过 提供 的 两 个 方法 进行 判断 的 。 对 应 非 基 于 Tungsten Sort 时 ， 通 过 SortShuffleWrit- 
er. shouldBypassMergeSort 方法 判断 是 否 需 要 回 退 到 Hash 风格 的 Shuffle 实现 机 制 ， 当 该 方法 
返回 的 条 件 不 满足 时 ， 则 通过 SortShuffleManager. canUseSerializedShuffle 方法 判断 是 否 需 要 采 
用 基于 Tungsten Sort 的 Shuffle 实现 机 制 ， 而 在 这 两 个 方法 的 返回 都 为 false， 即 都 不 满足 对 应 
的 条 件 时 ,会 自动 采用 常规 意义 上 的 基于 Sort 的 Shuffle 实现 机 制 。 

因此 ， 当 设置 了 spark. shuffle. manager = tungsten - sort 时 ， 也 不 能 保证 就 一 定 采 用 基于 
Tungsten Sort 的 Shuffle 实现 机 制 。 有 兴趣 的 读者 可 以 参考 Spark 1.5 及 之 前 的 注册 方法 的 实 
现 ， 该 实现 中 SortShuffleManager 的 注册 方法 仅 构建 了 BaseShuffleHandle 实例 ， 同 时 对 应 的 
getWriter 中 也 对 应 只 构建 了 BaseShuffleHandle 实例 。 


基于 Tungsten Sort 的 Shuffle 内 核 ) 


基于 Tungsten Sort 的 Shuffle 实现 机 制 的 入 口 点 仍然 是 SortShuffleManager 类 ， 与 同样 在 
SortShuffleManager 类 控制 下 的 其 他 两 种 实现 机 制 不 同 的 是 ， 基 于 Tungsten Sort 的 Shuffle 实现 
机 制 使 用 的 ShuffleHandle 与 ShuffleWriter 分 别 为 SerializedShuffleHandle 与 UnsafeShuffleWrit- 
er。 因 此 对 应 的 具体 实现 机 制 可 以 用 图 7-7 来 表示 。 


| SortShuffleManager 























registerShuffle[K, V, C] 





shuffleBlockResolver 


UnregisterShuffle 
stop() 














SerializedShuffleHandle < 
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| BlockStoreShuffleReader 
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图 7-7 基于 TungstenSort 的 Shuffle 实现 机 制 的 框架 类 医 
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在 基于 Sort 的 Shuffle 内 核 一 节 中 已 经 提 到 过 SortShuffleManager 根据 内 部 采用 的 不 同 实 
现 细节 ， 分别 给 出 两 种 排序 模式 ， 而 基于 Tungsten Sort 的 Shuffle 实现 机 制 对 应 的 就 是 序列 化 
排序 模式 。 

从 图 7-7 中 可 以 看 到 ， 基 于 Sort 的 Shuffle 实现 机 制 ， 具 体 的 写 人 器 的 选择 与 注册 得 到 
的 ShuffleHandle 类 型 有 关 ， 参 考 SortShuffleManager 类 的 registerShuffle 方法 ， 相 关 代 码 如 下 。 








]. /A** 

2 * Register a shuffle with the manager and obtain a handle for it to pass to tasks. 

3.  #* 向 ShuffleManager 注册 一 个 Shuffle 并 获取 一 个 ShuffleHandle， 

4. * 然后 传人 到 Tasks 中 。 在 Map 端的 Tasks 通过 该 ShuffleHandle 从 ShuffleManager 
5. ”<#* 获取 数据 写 和 人 器 ShuffleWriter, 对 应 Reduce 端的 Tasks 通过 该 ShuffleHandle 

6. * 从 ShuffleManager 获取 数据 读 取 器 ShuffleReader 

7 */ 

8. override def registerShuffle[K,V,C]( 

9. shuffleId : Int ， 

10. numMaps: Int, 

11. dependency:ShuffleDependency[K,V,C] ) :ShuffleHandle = | 

区 if( SortShuffleWriter. shouldBypassMergeSort( SparkEnv. get conf ,dependency) ) | 
13. 

14. // 

15. } else if(SortShuffleManager. canUseSerializedShuffle( dependency) ) { 

16. // Otherwise,try to buffer map outputs in a serialized form ,since this is more efficient: 
17. // 当 可 以 使 用 序列 化 模式 时 ,可 以 直接 以 序列 化 的 个 数 输出 数据 ,这 可 以 减少 内 
18. // 存 开销 和 序列 化 、 反 序列 化 方面 的 CPU 开销 等 ,因此 会 更 加 高 效 

19. new SerializedShuffleHandle[ K,V |( 

20. shuffleId ,numMaps , dependency. asInstanceOf[ ShuffleDependency[ K,V,V]]) 
2il, | else | 

223 

23. | 

24. |】 

















在 第 15 行 代 码 处 ， 会 判断 是 否 满足 序列 化 模式 的 条 件 ， 如 果 满 足 ， 则 使 用 基于 Tung- 
stenSort 的 Shuffle 实现 机 制 ， 对 应 在 代码 中 表现 为 使 用 类 型 为 SerializedShuffleHandle 的 Shuf- 
fleHandle。 上 述 代码 进一步 说 明了 在 将 “spark. shuffle. manager” 设 置 为 sort 时 ， 内 部 会 自动 
选择 具体 的 实现 机 制 。 对 应 代码 的 先后 顺序 就 是 选择 的 先后 顺序 。 

对 应 的 序列 化 排序 〈Serialized sorting) 模式 需要 满足 的 条 件 如 下 。 

1) Shuffle 依赖 中 不 带 聚 合 操作 或 没有 对 输出 进行 排序 的 要 求 。 

2) Shuffle 的 序列 化 器 支持 序列 化 值 的 重 定位 〈 当 前 仅仅 支持 KryoSerializer 及 Spark 
SQL 子 框架 自 定义 的 序列 化 器 ) 。 

3) Shuffle 过 程 中 的 输出 分 区 个 数 少 于 16777216 个 。 

实际 上 ， 使 用 过 程 中 还 有 其 他 一 些 限 制 ， 比 如 由 于 使 用 Page 形式 的 内 存 管理 模型 后 ， 
内 部 单条 记录 的 长 度 不 能 超过 128 MB (具体 内 存 模 型 可 以 参考 PackedRecordPointer 类 ) 。 另 
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外 分 区 个 数 的 限制 也 是 该 内 存 模 型 导致 的 (同样 参考 PackedRecordPointer 类 ) 。 
所 以 ， 目 前 使 用 基于 TungstenSort 的 Shuffle 实现 机 制 的 条 件 还 是 比较 苛刻 的 。 











| 基于 Tungsten Sort 的 Shuffle 写 数 据 的 源 代 码 解 术 OO) 


对 应 这 种 SerializedShuffleHandle 及 其 相关 的 Shuffle 数据 写 人 器 类 型 的 相关 代码 可 以 参考 
SortShuffleManager 类 的 getWriter 方法 ， 关 键 代 码 如 下 。 
































1. /** 为 指定 的 分 区 提供 一 个 数据 写 人 器。 该 方法 在 Map 端的 Tasks 中 调用 */ 
2 / ** Get a writer for a given partition. Called on executors by map tasks. */ 

3 override def getWriter[ K,V]( 

4. handle: ShuffleHandle, 

S: mapld : Int, 

6. context :TaskContext ) :ShuffleWriter[ K,V | = | 

ge numMapsForShuffle. putIfAbsent( 

8. handle. shuffleId ,handle. asInstanceOf| BaseShuffleHandle[ _,_,_| |]. numMaps) 
9 val env = SparkEnv. get 

10. handle match | 

11.//SerializedShuffleHandle 对 应 的 写 和 器 为 UnsafeShuffleWriter 

la // 使 用 的 数据 块 逻 辑 与 物理 映射 关系 仍然 为 mdexShuffleBlockResolver ,对 应 
13. //SortShuffleManager 中 的 变量 ,因此 相同 

14. case unsafeShuffleHandle :SerializedShuffleHandle[ K @ unchecked,V @ unchecked| => 
15. new UnsafeShuffleWriter( 

16. env. blockManager， 

站 六 shuffleBlockResolver. asInstanceOf[ IndexShuffleBlockResolver | ， 

18. context. taskMemoryManager( ) ， 

19. unsafeShuffleHandle, 

20. mapld, 

2 context, 

2 env. conf) 

23: | 

24. } 





在 数据 写 入 器 类 UnsafeShuffleWriter 中 ,使 用 的 仍然 是 SortShuffleManager 实例 中 的 变量 
shuffleBlockResolver 来 对 逻辑 数据 块 与 物理 数据 块 的 映射 进行 解析 ， 而 该 变量 使 用 的 是 与 基 
于 Hash 的 Shuffle 实现 机 制 不 同 的 解析 类 ， 即 当前 使 用 IndexShuffleBlockResolver。 

在 第 18 行 代码 中 ， 可 以 看 到 UnsafeShuffleWiriter 构建 时 传人 了 一 个 与 其 他 两 种 基于 Sor- 
ted 的 Shuffle 实现 机 制 不 同 的 参数 .context. taskMemoryManager( ) ， 在 此 构建 了 一 个 Task- 
MemoryManager 实例 并 传人 UnsafeShuffleWriter，TaskMemoryManager 与 Task 是 一 对 一 的 关 
系 ， 负 责 管 理 分 配给 Task 的 内 存 。 

下 面 开 始 解析 写 数据 块 的 UnsafeShuffleWriter 类 的 源 代 码 实 现 。 首 先 查看 其 write 的 方法 ， 
代码 如 下 。 
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1. @ Override 

四 public void write( scala. collection. Iterator < Product2 < K,V >> records )throws IOException | 
3 

4. try | 

5 // 对 输入 的 记录 集 records ,循环 将 每 条 记录 插 和 人 到 外 部 排序 器 。 

6. while( records. hasNext( ) ) | 

5 insertRecordIntoSorter( records. next( ) ) ; 

8. } 

9. // 生 成 最 终 的 两 个 结果 文件 ,和 Sorted Based Shuffle 的 实现 机 制 一 样 ， 
10.，// 每 个 Map 端的 任务 对 应 生成 一 个 数据 (Data) 文件 和 对 应 的 索引 (Index) 文 件 。 
11. closeAndWriteOutput( ) ; 

2 success = true; 

13. 上 finally | 

14. if( sorter | = null) | 

15. try | 

16. // 释 放 排序 过 程 中 使 用 的 资源 

Ws sorter. cleanupResources( ) ; 

18. | catch( Exception e) | 

19. 

20. 

21. | 

二 

2 





写 过 程 中 的 关键 步骤 只 有 3 步 。 

1) 第 5 ~7 行将 每 条 记录 插入 外 部 排序 器 。 

2) 第 11 行 , 写 数据 文件 与 所 有 文件 ， 在 写 的 过 程 中 ,会 先 合 并 外 部 排序 带 在 搬入 过 
程 中 生成 的 Spill 中 间 文 件 。 

3) 第 17 行 ， 最 后 释放 外 部 排序 器 的 资源 。 














首先 查看 将 每 条 记录 插入 外 部 排序 器 ( ShuffleExternalSorter) 时 所 使 用 的 insertRecordIn- 
toSorter 方法 ， 其 关键 代码 如 下 。 





1. void insertRecordIntoSorter( Product2 < K,V > record )throwsIOException | 
2 assert( sorter | = null) ; 

3. /对 于 多 次 访问 的 Key 值 ,使 用 局 部 变量 ,可 以 避免 多 次 函数 调用 

4. /有 兴趣 的 读者 可 以 跟踪 一 下 spark 的 issues 相关 内 容 , 对 于 元 组 在 
5. // 模 式 匹 配 等 方面 优化 的 一 些 细节 处 理 
6 

Wy 

8 

9 


























final K key = record. _1( ); 
final intpartitionId = partitioner. getPartition( key ) ; 
// 先 复位 存放 每 条 记录 的 缓冲 区 
// 内 部 使 用 ByteArrayOutputStream 存放 每 条 记录 ,容量 为 1MB 




















10. serBuffer. reset( ) ; 
11. // 进 一 步 使 用 序列 化 器 从 serBuffer 缓冲 区 构建 序列 化 输出 流 ,将 记录 写 和 人 到 缓冲 区 
U2 serOutputStream. writeKey( key, OBJECT_CLASS_TAG); 
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13. serOutputStream. writeValue(record. 2() ,OBJECT_ CLASS_TAC ) ; 

14. serOutputStream. flush( ) ; 

15. 

16. final int serializedRecordSize = serBuffer. size( ) ; OO 
17. assert( serializedRecordSize > 0); 

18. 

19. // 将 记录 插 和 人 到 外 部 排序 器 中 ,serBuffer 是 一 个 字 节 数组 

20. // 内 部 数据 存放 的 偏 移 量 为 Platform. BYTE_ARRAY_OFFSET 

2 sorter. insertRecord ( 

2 serBuffer. getBuf( ) ,Platform. BYTE_ARRAY_OFFSET,serializedRecordSize ,partitionId ) ; 
38 } 





下 面 继续 查看 第 二 步 写 数据 文件 与 索引 文件 的 closeAndWriteOutput 方法 ， 其 关键 代码 
如 下 。 



























































| void closeAndWriteOutput( ) throws IOException | 

2 

3 // 设 为 null, 用 于 GC 垃圾 回收 

4. serBuffer = null; 

3 serOutputStream = null; 

6. /关闭 外 部 排序 器 并 获取 全 部 Spil 信息 

ge finalSpillInfol ] spills = sorter. closeAndGetSpills( ); 

8. sorter = null; 

9. final long[ | partitionLengths; 

10. // 通 过 块 解析 器 获取 输出 文件 名 

11. final File output = shuffleBlockResolver. getDataFile( shuffleld ,mapId ) ; 

12. // 在 后 续 合 并 Spill 文件 时 先 使 用 临时 文件 名 ,最 终 再 重 命名 为 真正 的 输出 文件 名 。 

13. // 即 在 writeIndexFileAndCommit 方 法 中 会 重复 通过 块 解析 器 获取 输出 文件 名 

14. final Filetmp = Utils. tempFileWith(output ) ; 

LS try | 

16. partitionLengths = mergeSpills( spills, tmp) ; 

17. | finally | 

18. /清理 中 间 生 成 的 Spill 文件 

19. 

20. } 

21. // 将 合并 Spill 后 获取 的 分 区 及 其 数据 量 信息 写 入 索引 文件 ， 

2 // 并 将 临时 数据 文件 重 命名 为 真正 的 数据 文件 名 

23. shuffleBlockResolver. writeIndexFileAndCommit( shuffleId ,mapId , partitionLengths ,tmp ) ; 

24. mapStatus = MapStatus $. MODULE $. apply ( blockManager. shuffleServerld ( ), partition- 
Lengths ) ; 

25 0 
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closeAndWriteOutput 方法 主要 有 以 下 几 步 。 

1) 触发 外 部 排序 器 ， 获 取 Spil 信息 。 

2) 合并 中 间 的 Sp 记 文件 ， 生 成 数据 文件 ， 并 返回 各 个 分 区 对 应 的 数据 量 信息 。 
3) 根据 各 个 分 区 的 数据 量 信息 生成 数据 文件 对 应 的 索引 文件 。 








由 于 writeIndexFileAndCommit 方法 和 前 面 Sorted Based Shuffle 机 制 的 实现 一 样 ， 在 此 仅 
分 析 过 程 中 不 同 的 Spil 文件 合并 步 又 ， 即 mergeSpills 方法 的 具体 实现 。 
mergeSpills 方法 的 关键 代码 如 下 。 


SO 


一 二 一 王 
0 


pe 


15. 








水 水 


* Merge zero or more spill files together ,choosing the fastest merging strategy based on 
* the number of spills and the IO compression codec. 

六 

* @ return the partition lengths in the merged file. 

* 

* 合并 0 个 或 多 个 spill 的 中 间 文 件 ,基于 Spills 的 个 数 以 及 10 压缩 码 选择 最 快 
* 速 的 合并 策略 。 返 回 包含 合并 文件 中 各 个 分 区 的 数据 长 度 的 数组 。 

*/ 














private long| ] mergeSpills( SpillInfol ] spills, File outputFile ) throws IOException | 





/获取 Shuffle 的 压缩 配置 信息 

final boolean compressionEnabled = sparkConf getBoolean(" spark. shuffle. compress" ,true ) ; 
final CompressionCodec compressionCodec = CompressionCodec$. MODULES. createCodec ( spark- 
Conf ) ; 

// 获 取 是 否 启动 unsafe 的 快速 合并 

final boolean fastMergeEnabled = 





sparkConf. getBoolean( " spark. shuffle. unsafe. fastMergeEnabled" ,true); 
// 没 有 压缩 或 者 当 压 缩 码 支 持 序列 化 流 合并 时 ,支持 快速 合并 


final boolean fastMergelsSupported = ! compressionEnabled || 





CompressionCodec$. MODULES. supportsConcatenationOfSerializedStreams( compressionCodec ) ; 


try | 
if( spills. length ==0)| 
// 没 有 中 间 的 spills 文件 时 ,创建 一 个 空 文件 ,并 返回 包含 分 区 数据 长 度 的 
// 空 数组 。 后 续 读 取 时 会 过 滤 掉 空 文件 
new FileOutputStream( outputFile ). close( ) ; // Create an empty file 














return new long| partitioner numPartitions( ) ] ; 


else if( spills. length ==1)| 

// 最 后 一 个 spills 文件 已 经 更 新 metrics 信息 ,因此 不 需要 重复 更 新 
// 直 接 重 命名 spills 的 中 间 临 时 文件 为 目标 输出 的 数据 文件 

// 同 时 将 该 spills 中 间 文 件 的 各 分 区 数据 长 度 的 数组 返回 即 可 


// Here,we don t need to perform any metrics updates because the bytes written to this 





























// output file would have already been counted as shuffle bytes written. 
Files. move( spills| 0 ]. file ,outputFile ) ; 
return spills[ 0 ]. partitionLengths; 


| else | 
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33: final long[ | partitionLengths; 

36. //” 当 存在 多 个 Spill 中 间 文 件 时 ,根据 不 同 的 条 件 , 采 用 不 同 的 文件 合并 策略 
引信 if(fastMergeEnabled && fastMergeIsSupported ) | 

38. // 由 "spark. file. transferTo" 配置 属性 控制 ,默认 为 true。 O) 
39. if(transferToEnabled ) | 

40. logger. debug( " UsingtransferTo - based fast merge" ) ; 

41. // 通 过 NIO 的 方式 合并 各 个 spills 的 分 区 字 节 数据 

42. // 仪 在 I0 压缩 码 和 序列 化 器 支持 序列 化 流 的 合并 时 安全 

43. partitionLengths = mergeSpillsWithTransferTo( spills ,outputFile ) ; 

44. | else | 

45. logger. debug( " UsingfileStream — based fast merge" ) ; 

46. partitionLengths = mergeSpillsWithFileStream( spills ,outputFile ,null ) ; 

47. } 

48. | else | 

49. // 使 用 Java FileStreams 文件 流 的 方式 进行 合并 

50. partitionLengths = mergeSpillsWithFileStream( spills ,outputFile ,compressionCodec ) ; 
51. } 

52. // 更 新 Shuffle 写 数据 的 度量 信息 

53. writeMetrics. decShuffleBytesW ritten ( spills[ spills. length — 1 ]. file. length( ) ) ; 

5 writeMetrics. incShuffleBytesWritten( outputFile. length( ) ) ; 

S53; returnpartitionLengths ; 

56. } 

Sw 

58. | 

59. |} 


各 种 合并 策略 在 性 能 上 具有 一 定 的 差异 ,会 根据 具体 的 条 件 采用 ， 主 要 有 基于 NIO 和 基于 普 
通 文件 流 合并 文件 的 方式 。 下 面 简单 描述 一 下 基于 文件 合并 流 的 处 理 过 程 ， 代 码 如 下 。 


Ea 





于 /*#* 使 用 Java FileStreams 文件 流 的 方式 进行 合并 * / 

2. private long[ | mergeSpillsWithFileStream( 

3 SpillInfol ] spills, 

4. FileoutputFile, 

SE @ Nullable CompressionCodec compressionCodec ) throws IOException | 
6. assert( spills. length > =2); 

yA final intnumPartitions = partitioner. numPartitions( ) ; 

8. final long[ |partitionLengths = new long| numPartitions | ; 

9. 

10. // 对 应 打开 的 输入 流 的 个 数 为 spills 的 临时 文件 个 数 

11. finalInputStream| | spillInputStreams = new FileInputStream| spills. length ] ; 
I OutputStream mergedFileOutputStream = null; 

13. 

14. booleanthrewException = true; 

15. try | 
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16. // 为 每 个 spills 中 间 文 件 打开 文件 输入 流 

17. for(Cinti=0; i< spills. length; i ++ )| 

18. spillInputStreams[ i| = new FileInputStream( spills[ ij. file) ; 

19. | 

20. 

2 /遍历 分 区 

2 for( int partition =0; partition < numPartitions; partition ++ ) | 

2 final long initialFileLength = outputFile. length( ) ; 

24. // 构 建 各 个 分 区 对 应 的 合并 文件 输出 流 

25. mergedFileOutputStream = 

26. new TimeTrackingOutputStream( writeMetrics ,new FileOutputStream( outputFile ,true) ) ; 

27: if( compressionCodec ! = null)| 

28. mergedFileOutputStream = compressionCodec. compressedOutputStream ( mergedFile- 
OutputStream ) ; 

29. | 

30. 

31. // 依 次 从 各 个 Spills 输入 流 中 读 取 当前 分 区 的 数据 长 度 指定 个 数 的 字 节 

32. // 到 各 个 分 区 对 应 的 输出 文件 流 中 

33. for(int i=0; i<spills. length; i++ )| 

34. 

25 } 

36. mergedFileOutputStream. flush( ) ; 

要 人 mergedFileOutputStream. close( ) ; 

38. // 将 当前 写 入 的 数据 长 度 存 人 返回 的 数组 中 

39. partitionLengths| partition | = (outputFile. length( ) - initialFileLength ) ; 

40. | 

41. threwException = false; 

42 | finally | 

43. 人 

44. returnpartitionLengths; 

45. | 


基于 NIO 的 文件 合并 流程 基本 类 似 ， 只 是 底层 采用 了 NIO 的 技术 实现 。 
| Section | 


小 人 


本 章 内 容 围绕 对 集群 性 能 有 巨大 影响 的 Shuffle 实现 机 制 展开 ， 介 绍 了 在 Spark 计算 框架 
中 Shuffle 实现 机 制 的 演进 过 程 ， 以 及 在 各 个 演进 过 程 中 各 实现 机 制 的 优 缺 点 。 之 后 用 Shuf- 
fle 的 框架 解析 作为 起 点 ， 逐 步 从 整个 可 搬 拔 框架 到 各 个 具体 实现 机 制 的 内 部 框架 ， 比 较 详 
细 地 解析 各 Shuffle 框架 整体 组 成 结构 及 对 外 提供 的 处 理 流程 ， 并 结合 各 个 实现 机 制 内 部 的 
关键 源 代码 的 解析 来 加 深 对 Spark 的 Shuffle 框架 的 理解 。 
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第 8 闹 钢丝 计划 (Project Tungsten ) > 


Spark 计算 框架 备 受 瞩目 的 原因 之 一 在 于 它 的 高 性 能 ， 因 此 对 性 能 的 追求 一 直 是 其 主要 
目标 之 一 ， 在 通过 深入 分 析 Spark 计算 框架 性 能 的 瓶 宦 之 后 ， 引 入 了 铭 丝 计划 ， 该 计划 极 大 
地 提高 了 Spark 计算 框架 的 性 能 。 








钨 丝 计 划 ( Project Tungsten) 概述 





在 Spark 的 近期 发 展 中 ， 最 引 人 关 注 的 是 钨 丝 计 划 ( Project Tungsten ) 。 该 计划 可 以 从 
Databricks 公司 发 布 的 官方 博客 获取 (具体 参考 地 址 为 https://databricks. com/blog/2015/04/ 
28/project - tungsten - bringing - spark - closer - to - bare - metal. html ) ， 从 该 博客 中 可 以 知 
道 ， 目 前 制约 Spark 计算 框架 性 能 的 瓶颈 主要 在 于 CPU 与 内 存 ， 而 不 是 磁盘 IO 及 网 络 开销 
一 一 随 着 带宽 增长 、SSD 或 者 磁盘 阵列 的 使 用 ， 这 部 分 开销 已 经 不 再 是 Spark 计算 框架 的 瓶 
人 颈 。 因 此 ， 作 为 Spark 性 能 提升 的 下 一 阶段 的 钨 丝 计 划 (Project Tungsten) 也 就 因此 诞生 了 。 

关于 性 能 方面 的 详细 信息 ， 可 以 参考 上 述 博客 中 的 相关 介绍 ， 以 及 《 Making Sense of 
Performance in Data Analytics Frameworks》 这 篇 论文 。 

Project Tungsten 主要 包含 以 下 三 大 方面 。 

e 内 存 管 理 (Memory Management) 和 二 进 制 处 理 (Binary Processing) : 利用 面向 应 用 的 语义 

(application semantics) 来 更 明确 地 管理 内 存 ， 同 时 消除 JVM 对 象 模型 和 垃圾 回收 开销 。 

e 缓存 友好 的 计算 〈Cache - aware Computation ) : 使 用 算法 和 数据 结构 来 实现 内 存 分 级 

结构 (Memory Hierarchy) 。 

e 代码 生成 〈Code Generation ，CG) : 使 用 代码 生成 来 利用 新 型 编译 器 和 CPU。 

当前 钨 丝 计 划 的 详细 信息 可 以 参考 官网 上 的 两 个 开发 阶段 ， 如 图 8-1 和 图 8-2 所 示 。 















































Spark / SPARK-7075 
Sook Project Tungsten (Spark 1.5 Phase 1) 
Agile Board 
Details 
Type @ Epic Status 
Priority 个 Major Resolution Fixed 
Affects Version/s None Fix Version/s 1.5.0 
Component/s Block Manager, Shuffle, Spark Core, SQL 
Labels None 
Epic Name Tungsten Phase 1 
Target Version/s 1.5.0 











图 8-1 Project Tungsten 第 一 阶段 
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Spark / SPARK-9697 
spoik’ Project Tungsten (Phase 2) 
Agile Board 
Details 
Type Epic Status EDI 
Priority 个 Major Resolution Unresolved 
Affects Version/s None Fix Version/s None 
Component/s Block Manager, Shuffle, Spark Core, SQL 
Labels None 
Epic Name Tungsten Phase 2 














图 8-2 ”Project Tungsten 第 二 阶段 

更 多 Project Tungsten 内 容 可 以 跟踪 这 两 个 阶段 的 各 个 问题 (Issue) 。 

本 章 的 主要 目的 在 于 通过 解析 Spark 内 核 部 分 与 Project Tungsten 有 关 的 内 容 。 对 应 Spark SQL 
部 分 与 Project Tungsten 相关 的 源 代码 ， 解析 的 方式 基本 是 一 致 的 » 日 部 分 设计 文档 在 官方 资料 (万 
其 是 Issue) 中 很 多 都 已 经 给 出 ， 而 且 非 常 详 细 ， 因 此 本 章 不 再 重复 这 部 分 内 容 。 




















医 逐 昼 内 存 管理 模型 
区 2 现 有 内 存 管 理 的 机 制 





Spark 计算 框架 是 基于 Scala 与 Java 语言 开发 的 ， 其 底层 都 使 用 了 JVM。 而 在 JVM 上 运行 的 
应 用 程序 是 依赖 JVM 的 垃圾 回收 机 制 来 管理 内 存 的 ， 随 着 Spark 应 用 程序 性 能 的 不 断 提升 ，JVM 
对 象 和 GC 开销 产生 的 影响 (包括 内 存 不 足 、 频 繁 GC 或 FulGC) 将 非常 致 合 。 即 引进 新 的 Tung- 
sten 内 存 管理 机 制 的 主要 原因 在 于 优化 JVM 在 内 存 方面 和 GC 方面 的 开销 。 主 要 包含 两 个 方面 。 

1. JVM 对 象 模型 (JVM object model) 的 内 存 开销 

可 以 通过 Java Object Layout 工具 来 查看 在 JVM 上 Java 对 象 所 占用 的 内 存 空 间 (有 兴趣 的 
读者 可 以 参考 http://openjdk. java. net/projects/code - tools/jol/) ， 需 要 注意 的 是 在 32 位 与 64 
位 的 操作 系统 中 ， 占 用 空间 会 有 所 差异 ， 下 面 是 在 64 位 操作 系统 上 对 String 的 分 析 结 


1. java. lang. String object internals : 

2. OFFSET SIZE TYPE DESCRIPTION VALUE 

3 0 12 (object header ) N/A 

4. 12 4 charl ] String. value N/A 

号 16 4 int String. hash N/A 

6 20 4 int String. hash32 N/A 

7. Instance size:24 bytes( estimated ,the sample instance is not available) 
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8. Space losses :0 bytes internal + 0 bytes external = 0 bytes total 


一 个 简单 的 String 对 象 会 额外 占用 一 个 12 字 节 的 header 和 8 字 节 的 hash 信息 。 这 是 开 
启 (-XX:， +UseCompressed0ops， 默 认 ) 指针 压缩 方式 ( - XX: + UseCompressedOops) 的 结 























内 存 更 大 ， 如 下 所 示 。 


java. lang. String object internals: 
OFFSET SIZE TYPE DESCRIPTION 
0 16 (object header) 
16 8 char[ ] String. value 


28 4 int String. hash32 





果 ， 如 果 不 开 启 ( - XX: + UseCompressedOops ) 指针 压缩 ( - XX: + UseCompressedOops)， 则 


Instance size:32 bytes(estimated ,the sample instance is not available) 


1 
2 
3 
4 
5 24 4 int String. hash 
6 
7 
8 


Space losses :0 bytes internal +0 bytes external =0 bytes total 


其 中 ，Header 会 占用 16 个 字 节 的 大 小 ， 男 外 JVM 内 存 模型 会 采用 8 字 节 对 齐 ， 因 此 也 





可 能 会 再 增加 一 部 分 内 存 开销 。 





以 上 仅仅 是 String 对 象 中 JVM 内 存 模型 中 占用 的 内 存 大 小 ， 实 际 计算 时 需要 考虑 其 内 部 
的 引用 对 象 所 占 的 内 存 ， 通 过 分 析 ，char[ ] 中 默认 的 指针 压缩 情况 下 会 占用 16bytes 内 存 ， 
因此 仅仅 是 一 个 空 字 符 串 也 会 占用 2440bytes + 1640bytes =4 Kbytes 的 内 存 。 








另外 在 JVM 内 存 模型 中 ， 为 了 更 加 通用 ， 











Cae=: 





已 旦 


EE 新 定制 了 自己 的 储存 机 制 , 使 用 UTF - 


16 方式 编码 每 个 字符 (2 字 节 )。 可 以 参考 http://www. javaworld. com/article/2077408/core 
一 java/ sizeof -for -java. html ,java 对 象 的 内 存 占用 大 小 ， 如 下 所 示 。 


1l. // java. lang. Object shell size in bytes: 

2 public static final int OBJECT_SHELL _ SIZE =8; 
3 public static final int OBJREF_SIZE =4; 
4 public static final int LONC_FIELD_SIZE =8; 
S, public static final int INT_FIELD_SIZE =4; 
6 public static final int SHORT_FIELD_SIZE = 
7 public static final int CHAR_FIELD_SIZE 三 2 
8 public static final int BYTE_FIELD_SIZE = 
9 public static final int BOOLEAN_FIELD_SIZE =1; 
10. public static final int DOUBLE_FIELD_SIZE =8; 
Ll public static final int FLOAT_FIELD_SIZE =4; 


其 中 CHAR_FIELD_SIZE 为 2， 即 每 个 字符 串 在 JVM 中 采用 了 UTF -16 编码 ， 一 个 字符 


会 占用 两 个 字 节 。 


2. 垃圾 回收 机 制 ( Garbage collection,GC) 的 开销 

JVM 对 象 带 来 的 另 一 个 问题 是 CC。 通常 情况 下 ，JVXM 内 存 模型 中 的 Heap 会 分 成 两 
大 块 : Young Generation (年 轻 代 ) 和 0ld Generation (年 老 代 ) ， 其 中 年 轻 代 会 有 很 高 的 
allocation/deallocation ， 通 过 利用 年 轻 代 对 象 的 瞬时 特性 ， 垃 圾 收集 器 可 以 更 有 效率 地 对 其 
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进行 管理 ; 年 老 代 的 状态 则 非常 稳定 。GC 的 开销 在 所 有 基于 JVM 的 应 用 程序 中 都 是 不 可 
忽视 的 ， 而 且 对 应 的 调 优 也 非常 繁琐 ， 在 类 似 Spark 框架 这 样 的 基于 内 存 迭 代 处 理 的 框架 
中 ， 通 常 直 接 在 底层 对 内 存 进 行 管理 可 以 极 大 地 提高 效率 。 因 此 ， 对 应 引入 Project Tung- 
sten 也 就 很 合情合理 了 。 

下 面 的 章节 会 详细 解析 Project Tungsten 的 内 存 模型 及 其 源 代码 实现 ， 并 且 对 基于 该 模型 
的 Shuffle 写 数据 过 程 中 的 二 进 制 数据 处 理 也 给 出 了 详细 解析 。 








Project Tungsten 内 存 管 理 的 模型 及 其 源 代 码 的 解析 


在 2016 年 1 月 4 号 发 布 的 Spark 1.6 中 ， 提 出 了 一 个 新 的 内 存 管 理 模 型 ， 即 统一 内 存 管理 
模型 ， 对 应 在 Spark 1.5 及 之 前 的 版 本 则 使 用 静态 的 内 存 管 理 模 型 。 关 于 新 的 统一 内 存 管 理 模 
型 ， 可 以 参考 https://issues. apache. org/jira/secure/attachment/12765646/unified - memory - 
management - spark - 10000. pdf。 在 该 文档 中 详细 描述 了 各 种 可 能 的 设计 ， 以 及 各 设计 的 优 
缺点 。 另 外 ， 也 可 以 参考 网 上 对 Spark 内 存 管理 模型 解析 非常 深入 的 博客 http://0x0fff. com/ 
spark - memory - management/( Alexey Grishchenko) ， 博 客 内 容 包 含 了 静态 内 存 模型 管理 与 动 
态 内 存 模型 管理 的 详细 说 明 。 

为 了 解决 现 有 基于 JVM 托管 方式 的 内 存 模 型 所 存在 的 缺陷 ，Project Tungsten 设计 了 一 
套 新 的 内 存 管理 机 制 。 在 新 的 内 存 管理 机 制 中 ，Spark 的 Operation 可 以 直接 使 用 分 配 的 Bi- 
nary Data (二 进 制 数据 ) 而 不 是 JVM Objects。 避 免 了 数据 处 理 过 程 中 不 必要 的 序列 化 与 反 
序列 化 的 开销 ， 同 时 基于 Of - Heap 方式 管理 内 存 ， 降 低 了 GC 所 带 来 的 开销 。 

Project Tungsten 通过 sun. misc. Unsafe 来 管理 内 存 ， 关 于 sun. misc. Unsafe (从 命名 上 可 
知 该 工具 不 能 滥用 ) 及 其 使 用 等 内 容 ， 可 以 参考 官网 文档 http://www. docjar. com/ docs/ api/ 
sun/misc/Unsafe. html。 在 此 主要 分 析 Project Tungsten 中 的 内 存 管理 模型 的 具体 实现 。 

1，Project Tungsten 内 存 模 型 

Project Tungsten 内 存 管理 模型 主要 的 类 图 结构 如 图 8-3 所 示 。 


不 安全 内 存 分 配 堆 内 存 分 配 


存储 内 存 池 执行 内 存 池 
i 
























































分 配 / 释放 内 存 














图 8-3 Project Tungsten 内 存 管理 模型 主要 的 类 网 结构 

















在 图 8-3 中 ， 基 类 MemoryManager 封装 了 静态 内 存 管理 模型 与 统一 内 存 管理 模型 ， 即 分 
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别 对 应 两 个 具体 实现 子 类 StaticMemoryManger 与 UnitedMemoryManager。 对 应 的 内 存 分 配 由 
MemoryManager 的 成 员 tungstenMemoryMode 决定 ， 即 由 基 类 MemoryAllocator 负责 具体 内 存 分 
配 ， 对 应 Off - Heap 与 On - Heap 两 种 内 存 模式 ， 分 别 实现 了 两 个 具体 子 类 UnsafeMemoryAl- 
locator 与 HeapMemoryAllocator。MemoryAllocator 提供 了 Allocate 和 Free 两 个 成 员 函 数 来 提供 OO 
内 存 的 分 配 与 释放 ， 分配 的 内 存 以 MemoryBlock 来 表示 。 

另外 ， 根 据 内 存 使 用 目的 的 不 同 ， 将 内 存 分 为 两 大 部 分 : Storage 和 Execution， 对 应 的 
以 MemoryPool 的 两 个 具体 实现 子 类 StorageMemoryPool 与 ExecutionMemoryPool 对 其 进行 管理 。 
实际 上 除了 这 两 部 分 ， 总 的 内 存 还 包括 为 系统 预 留 的 OtherMemory。 

关于 内 存 分 类 及 其 对 应 管理 的 主要 类 之 间 的 关系 ， 可 以 通过 图 8-4 来 描述 。 

内 存 组 成 内 存 管理 














内 存 模式 


堆 执行 内 存 -一 
由 se 维 外 内 存 模式 
二 

堆 外 执行 内 存 


堆 内 存 模式 





JAVA 虚拟 机 


图 8-4 ”内 存 分 类 及 其 对 应 管理 的 主要 类 之 间 的 关系 














在 Worker 上 运行 的 每 个 Execution 进程 (抽象 描述 ， 实 际 对 应 各 部 署 场景 下 的 具体 Ex- 
ecutorBackend 实现 子 类 ) ， 对 应 由 一 个 MemoryManager 负责 管理 其 内 存 ， 即 图 8-4 中 Memo- 
ryManager 与 JVM 的 对 应 关系 为 1 :1。 

Storage 部 分 的 内 存 由 StorageMemoryPool 负责 管理 ，Execution 部 分 的 内 存根 据 不 同 的 内 
存 模式 ( MemoryMode ) 分 为 on - heap 与 off - heap 两 种 ， 分 别 由 onHeapExecutionMemoryPool 
与 offHeapExecutionMemoryPool 进行 管理 。 管 理 内 存 主 要 是 通过 内 存 使 用 量 进行 控制 ， 不 涉 
及 内 存 的 分 配 与 释放 。 

2. MemoryManager 的 实现 及 其 源 代码 解析 

MemoryManager 目前 实现 了 两 种 具体 的 内 存 管理 模型 ， 从 Spark 1.6 版 本 开始 ， 上 默认 使 
用 统一 内 存 管 理 模型 ， 对 应 的 配置 属性 为 " spark. memory. useLegacyMode" ， 控 制 代 码 位 于 
SparkEnv 类 中 ， 代 码 如 下 。 
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// Spatk 1.5 及 之 前 的 版 本 所 使 用 的 内 存 管理 模型 对 应 配置 属性 
//" spark. memory. useLegacyMode" 。 当 前 默认 为 false 
val useLegacyMemoryManager = conf. getBoolean( " spark. memory. useLegacyMode" ,false) 








val memoryManager: MemoryManager = 
if(useLegacyMemoryManager ) | 
// 使 用 静态 内 存 管理 模型 


new StaticMemoryManager( conf,numUsableCores ) 





| else | 
// 使 用 统一 内 存 管理 模型 
UnifiedMemoryManager(conf,numUsableCores ) 


1. 
2 
人 
4. 
S3 
6. 
8. 
9 


SS 


11. | 


以 上 是 选择 具体 采用 哪 种 内 存 管理 模型 的 代码 ， 下 面 开 始 分 析 与 内 存 管理 相关 的 源 代 
人 码 ， 首 先 查看 MemoryManager 的 注释 ， 代 码 如 下 。 








1l. /** 
2 * 内 存 管理 的 抽象 接口 ,用 于 指定 如 何在 Execution 与 Storage 间 共 享 内 存 

3 x* Execution Memory 是 指 用 计算 的 内 容 , 包 括 Shuffles ,joins \sorts 及 aggregations 

4 * Storage Memory 是 指 用 于 缓存 或 内 部 数据 传输 过 程 中 所 使 用 的 内 存 

SS * MemoryManager 与 JVM 进程 的 对 应 关系 为 1:1。 即 一 个 JVM 进程 中 的 内 存 由 一 个 
6 

8 

9 





























* MemoryManager 进行 管理 
*/ 


privatel spark | abstract class MemoryManager( 





在 MemoryManager 类 中 提供 的 内 存 分 配 与 释放 的 几 个 主要 接口 如 下 。 
e Storage 部 分 内 存 的 分 配 与 释放 接口 : acquireStorageMemory 、acquireUnrollMemory 、re- 
leaseStorageMemory 和 releaseUnrollMemory。 
e Execution 部 分 内 存 的 分 配 与 释放 接口 : acquireExecutionMemory 和 releaseExecution- 
Memory。 
内 存 具 体 分 配 与 释放 的 实现 由 MemoryManager 的 具体 子 类 提供 。 
两 大 实现 子 类 ( a oa 和 UnifiedMemoryManager) 的 主要 差别 在 于 Storage 
与 Execution 内 存 之 间 的 边界 是 静态 的 还 是 动态 可 变 的 ， 下 面 分 别 简单 描述 两 大 子 类 的 实现 
细节 。 
StaticMemoryManager 类 的 注释 如 下 所 示 。 











有 


+ A [[MemoryManager | | that statically partitions the heap space into disjoint regions. 


* 
* The sizes of the execution and storage regions are determined through 


* spark. shuffle. memoryFraction and' spark. storage. memoryFraction respectively. The two 


A po 


* regions are cleanly separated such that neither usage can borrow memory from the other. 
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7 * 静态 划分 Storage 与 Execution 内 存 之 间 的 边界 的 一 种 内 存 管理 实现 

8. * Storage 与 Execution 内 存 大 小 分 别 由 配置 属性 spark. shuffle. memoryFraction 与 

9. * spark. storage. memoryFraction 各 自 指定 ,由 于 是 静态 划分 边界 ,因此 这 两 者 之 间 不 能 
10. ”* 互相 借用 多 余 的 内 存 

ll. */ 





























12. private[ spark | class StaticMemoryManager( 


静态 内 存 管理 模型 中 各 部 分 内 存 的 分 配 可 以 通过 以 下 几 个 接口 或 成 员 变量 查看 。 

1) maxUnrollMemory: unroll 过 程 中 可 用 的 内 存 ， 占 最 大 可 用 Storage 内 存 的 0.2 ( 占 
比 》。 

2) getMaxStorageMemory: 获取 分 配给 Storage 使 用 的 最 大 内 存 大 小 。 

3) getMaxExecutionMemory: 获取 分 配给 Execution 使 用 的 最 大 内 存 大 小 。 

其 中 ，getMaxStorageMemory 对 应 用 于 Storage 的 最 大 内 存 ， 具 体 配 置 如 下 。 











private def getMaxStorageMemory( conf:SparkConf) :Long = | 

val systemMaxMemory = conf getLong("spark. testing. memory" ,Runtime. getRuntime. maxMemory ) 
val memoryFraction = conf getDouble(" spark. storage. memoryFraction" ,0. 6) 

val safetyFraction = conf getDouble( " spark. storage. safetyFraction" ,0. 9) 


(systemMaxMemory * memoryFraction * safetyFraction). toLong 


| 


其 中 配置 属性 spark. storage. memoryFraction 表示 Storage 内 存 占用 全 部 内 存 ( 除 预 留 给 系 
统 的 内 存 外 ) 的 占 比 ，spark. storage. safetyFraction 对 应 为 Storage 内 存 的 安全 系数 。 

相应 的 ，getMaxExecutionMemory 方法 指明 了 用 于 Execution 内 存 的 相关 配置 属性 5 5 
Storage 内 存 一 样 包含 占 总 内 存 的 占 比 (0.2) 及 对 应 的 安全 系数 。 

另外 ， 除 了 Storage 内 存 与 Execution 内 存 占 用 的 0.6 +0.2 之 外 的 剩余 内 存 ， 作 为 系统 
预 留 内 存 。 
通过 StaticMemoryManager 类 简单 分 析 静 态 内 存 管理 模型 后 ， 继 续 查 看 统一 内 存 管 理 模 
型 ， 首 先 查看 其 类 注释 。 


ES 二 

















l. /A/** 
2 x* UnifiedMemoryManager: 是 MemoryManager 的 一 个 具体 子 类 ,实现 Storage 与 
3 x* Execution 间 软 边界 ( 即 动 态 边 界 ) 的 内 存 管理 模式 

4 x* 动态 边界 意味 着 Storage 与 Execution 的 内 存 是 可 以 相互 借用 的 

3 * Storage 与 Execution :共享 的 内 存 通过 配置 spark. memory. fraction 进行 设置 
6 

7 

8 

9 




















* 两 者 间 的 内 存 分 配 通 过 配置 spark. memory. storageFraction 进行 设置 
* 内 存 借用 : 
* 1) Storage 可 以 借用 Execution 中 空闲 的 内 存 , 但 在 Execution 执行 需要 内 存 时 
* ”会 被 回收 (回收 缓存 内 存 , 直到 满足 执行 申请 的 内 存 ) 
10.”#* 2) 同样 ,Execution 也 可 以 借用 Storage 中 空闲 的 内 存 。 但 是 ,出 于 实现 的 复 
11. * ” 杂 性 考虑 (具体 可 以 参考 前 面 给 出 的 官方 设计 文档 ) 
12. * unified ~ memory - management — spark — 10000. pdf) ， 
























































14. 
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借用 的 内 存 永远 不 会 因为 Siorage 的 需要 而 进行 回收 


*/ 


private| spark | class UnifiedMemory Manager private[ memory | ( 


UnifiedMemoryManager 与 StaticMemoryManager 一 样 实现 了 MemoryManager 的 几 个 内 存 分 
配 和 释放 的 接口 ， 对 应 分 配 与 释放 接口 的 实现 ， 在 StaticMemoryManager 中 相对 比较 简单 ， 
而 在 UnifiedMemoryManager 中 ， 由 于 考虑 到 动态 借用 的 情况 ， 实 现 相对 比较 复杂 ， 具 体 细节 
可 以 参考 官方 提供 的 统一 内 存 管 理 设计 文档 及 相关 源 代 码 ， 比 如 针对 各 个 Task 如 何 保证 其 
最 小 分 配 的 内 存 (最 少 为 1/2N， 其 中 N 表示 当前 活动 状态 的 Task 个 数 ， 最 大 的 Task 个 数 
可 以 从 Executor 分 配 的 内 核 个 数 / 每 个 Task 占用 的 内 核 个 数 得 到 ) 等 。 

下 面 简单 分 析 一 下 统一 内 存 管理 模型 中 ，Storage 内 存 与 Execution 内 存 等 相关 的 配置 。 
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查看 方法 ， 具 体 代码 如 下 。 


交 癌 


返回 Execution 与 Storage 共享 的 最 大 内 存 
*/ 


private def getMaxMemory( conf: SparkConf) :Long = | 


val systemMemory = conf getLong( " spark. testing. memory" , Runtime. getRuntime. maxMemory ) 


// 系 统 预 留 的 内 存 大 小 ,默认 为 300MB 


ZH 


/结合 下 面 最 小 系统 内 存 的 限定 条 件 ( 硬 编码 方式 ,因此 修改 需要 重新 编译 ) ， 





























// 可 以 人 为 地 修改 该 配置 进行 测试 


val reservedMemory = conf. getLong( " spark. testing. reservedMemory" ， 


if( conf. contains( " spark. testing" ) )0 else RESERVED_SYSTEM_MEMORY_BYTES) 


当前 最 小 的 内 存 需 要 300 x1.5, 即 450 MB ,不 满足 该 条 件 时 会 报错 退出 


. Val minSystemMemory = reservedMemory *1.5 





if( systemMemory < minSystemMemory ) | 
throw new lllegalArgumentException( s" System memory $systemMemory must " + 
s" be at least $minSystemMemory. Please use a larger heap size. " ) 
| 
val usableMemory = systemMemory - reservedMemory 
// 当 前 Execution 与 Storage 共享 的 最 大 内 存 占 比 默认 为 0.75, 即 
// Execution 与 Storage 内 存 为 可 用 内 存 的 0.75; 
/用 户 内 存 为 可 用 内 存 的 (1 -0.75) =0.25 
// 由 于 前 面 提 到 的 Alexey Grishchenko 给 出 的 博客 上 对 统一 内 存 管理 模型 给 出 了 














. /非常 详细 、 深 入 的 解析 ,建议 直接 参考 博客 内 容 ,同时 结合 此 处 源 代 码 进行 理解 


val memoryFraction = conf. getDouble( " spark. memory. fraction" ,0.75 ) 


(usableMemory * memoryFraction). toLong 
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另外 ， 虽 然 Execution 与 Storage 之 间 共享 内 存 ， 但 仍然 存在 一 个 初始 边界 值 ， 参 考 伴生 
对 象 UnifiedMemoryManager 的 apply 工厂 方法 ， 具 体 代 码 如 下 。 


def apply(conf:SparkConf,numCores:Int) :UnifiedMemoryManager = | 
val maxMemory = getMaxMemory ( conf) O) 
new UnifiedMemoryManager( 
conf, 


1 
2 
3 
4 
3 maxMemory = maxMemory ， 
6 
& 
8 
9 











// 通过 配置 属性 "spark. memory. storageFraction" ,可 以 设置 Execution 与 Storage 
/共享 内 存 的 初始 边界 值 , 即 默认 初始 化 时 ,各 占 总 内 存 的 一 羊 


storage RegionSize = 





(maxMemory x* conf getDouble( " spark. memory. storageFraction" ,0. 5) ). toLong, 
10. numCores = numCores ) 


11. } 











另外 需要 注意 的 是 ， 前 面 Execution 内 存 指 的 是 ON_HEAP 部 分 的 内 存 ， 在 ProjectTung- 
sten 中 引入 了 OFF_HEAP ( 堆 外 ) 内存， 这 部 分 内 存 大 小 的 设置 在 基 类 MemoryManager 中 ， 
对 应 代码 如 下 。 





// 根 据 传人 的 内 存 大 小 或 配置 属性 分 别 设置 内 存 池 管理 的 内 存 初 始 大 小 
//1.，Storage 部 分 的 内 存 池 初 始 大 小 设置 
storageMemoryPool. incrementPoolSize( storage Memory ) 

// 2. ON_HEAP 部 分 的 Execution 内 存 池 初 始 大 小 设置 
onHeapExecutionMemoryPool. incrementPoolSize( onHeapExecutionMemory ) 

// 3. 从 配置 属性 中 读 取 OFF_HEAP 内 存 池 的 初始 内 存 大 小 

offHeapExecutionMemoryPool. inerementPoolSize( conf getSizeAsBytes( " spark. memory. offHeap. size" ,0) ) 
































SS re es 








当 需 要 使 用 OFF_HEAP 内 存 时 ， 需 要 注意 的 是 ， 除 了 需要 修改 OFF_HEAP 内 存 池 (off- 
HeapExecutionMemoryPool) 的 内 存 初始 值 (默认 为 0) 外 ， 还 需要 打开 对 应 的 控制 开关 ， 具 
体 代码 参考 内 存 分 配 MemoryManager 中 内 存 模式 的 设置 (该 内 存 模式 可 以 控制 用 于 内 存 分 配 
MemoryAllocator 的 具体 子 类 ) ， 对 应 代码 如 下 。 


























1 final val tungstenMemoryMode: MemoryMode = | 

2. ”// 当 需要 使 用 OFF_HEAP 内 存 模式 时 ,需要 通过 " spark. memory. offHeap. enabled" 
3 // 配 置 属性 打开 开关 ,然后 通过 " spark. memory. offHeap. size" 配置 属性 

4 // 指 定 OFF_HEAP 的 内 存 大 小 

5, if( conf. getBoolean( " spark. memory. offHeap. enabled" ,false ) ) | 

6 require( conf. getSizeAsBytes( " spark. memory. offHeap. size" ,0) >0， 

也 "spark. memory. offHeap. size must be >0 when spark. memory. offHeap. enabled == true" ) 
8 MemoryMode. OFF_HEAP 

9 | else | 

10. MemoryMode. ON_HEAP 

ii | 

| } 
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从 图 8-4 中 可 以 看 出 ，Execution 内 存根 据 不 同 的 内 存 模式 (ON_HEAP 或 OFF_HEAP) 
可 以 有 两 种 内 存 池 管理 方式 ， 可 以 查看 一 下 Execution 内 存 分 配 的 方法 ， 关 键 代 码 如 下 。 


(对 应 配置 
Storage 也 可 以 向 ON_HEAP 这 部 分 Execution 借用 内 存 。 











override private[ memory | def acquireExecutionMemory( 


numBytes: Long, 
taskAttemptld :Long, 
memoryMode: MemoryMode ) :Long = synchronized | 


assert( onHeapExecution MemoryPool. poolSize + storageMemoryPool. poolSize == maxMemory ) 
assert( numBytes >= 0) 


memoryMode match | 


case MemoryMode. ON_HEAP => 











// 当 内 存 模 式 为 ON_HEAP 时 ,使 用 onHeapExecutionMemoryPool 内 存 池 来 管理 


onHeapExecution MemoryPool. acquire Memory( 














numBytes ,taskAttemptId ,maybeCrowExecutionPool ,computeMaxExecutionPoolSize ) 


case MemoryMode. OFF_HEAP => 
// 当 内 存 模 式 为 OFF_HEAP 时 ,使 用 offHeapExecutionMemoryPool 内 存 池 来 管理 
offHeapExecution MemoryPool. acquire Memory( numBytes ,taskAttemptId ) 

















MemoryMode 是 二 选 一 ， 因 此 在 启动 OFF_HEAP 内 存 模式 时 ， 可 以 将 Storage 的 内 存 占 比 
属性 " spark. memory. storageFraction" ) 设置 得 高 一 点 ,虽然 在 具体 分 配 过 程 中 


关于 内 存 池 部 分 ， 下 面 给 出 主要 类 的 类 图 ， 具 体 实现 可 以 结合 类 图 阅读 源 代码 来 加 深 理 
解 ， 主 要 类 图 如 图 8-5 所 示 。 


增加 内 存 池 大 小 
减少 内 存 池 大 小 






内 存 池 
内 存 池 大 小 








执行 内 存 池 



















存储 内 存 池 
已 使 用 内 存 
从 存储 内 存 


空间 释放 掉 
block 的 空间 


从 存储 内 存 池 中 获取 内 存 空间 





图 8-5 内存 池 相 关 类 图 
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主要 通过 内 部 池 大 小 和 使 用 的 内 存 大 小 等 进行 控制 ， 对 应 统一 内 存 管理 模型 ， 需 要 考虑 
借用 等 具体 实现 (关键 代码 可 以 查看 UnitedMemoryManager 对 StorageMemoryPool 类 的 shrink- 
PoolToFreeSpace 方法 的 调用 ) 。 

以 上 是 对 Tungsten 的 两 种 内 存 管 理 模型 的 简单 解析 。 下 面 开始 对 内 存 管理 模型 的 内 部 组 O) 
织 结构 进行 解析 。 

3. Project Tungsten 内 存 管 理 模型 中 对 内 存 描述 的 封装 

关于 Project Tungsten 的 相关 内 容 ， 可 以 参考 https://github. com/hustnn/ TungstenSecret。 
其 中 对 Page Table 给 出 了 描述 非常 详细 的 说 明 图 。 

下 面 从 最 基本 的 源 代码 开始 逐步 分 析 内 存 管 理 模 型 中 内 存 描述 的 封装 ， 主 要 包含 内 存 地 
址 的 封装 和 内 存 块 的 封装 ， 分 别 对 应 MemoryLocation 和 MemoryBlock 。 

在 Project Tungsten 中 ， 为 了 统一 管理 ON_HEAP 和 OFF_HEAP 两 种 内 存 模式 ， 引 入 了 统 
一 的 地 址 表示 形式 ， 即 通过 MemoryLocation 类 来 表示 ON_HEAP 或 OFF_HEAP 两 种 内 存 模式 
下 的 地 址 。 

首先 查看 该 类 的 注释 信息 ， 有 具体 如 下 所 示 。 























/六 六 

* A memory location. Tracked either by a memory address( with OFF_HEAP allocation ) ， 

# or by an offset from a JVM object( in - heap allocation ) . 

* 一 个 内 存 地 址 。 用 于 跟踪 OFF_HEAP 模式 下 的 内 存 地 址 或 ON_HEAP 模式 下 的 内 存 地 址 
*/ 


public class MemoryLocation | 





Ar 


当 使 用 OFF_HEAP 内 存 模式 时 ， 内 存 地 址 可 以 通过 64 位 的 绝对 地 址 来 描述 ， 相 应 的 ， 
当 使 用 ON_HEAP 内 存 模式 时 ， 由 于 GC 过 程 中 会 对 堆 (heap) 内 存 进行 重组 ， 因 此 地 址 的 
定位 需要 通过 对 象 在 堆 内 存 的 引用 及 在 该 对 象 内 的 偏 移 量 来 表示 ， 此 时 便 需 要 对 象 引用 和 一 
个 偏 移 量 来 表示 内 存 地 址 。 

因此 ， 在 MemoryLocation 中 定义 了 两 个 成 员 变 量 ， 具 体 代码 如 下 。 














1l.  @ Nullable 
2. ”Object obj; 
3. long offset ; 


对 应 两 种 不 同 的 内 存 模式 ， 两 个 成 员 变 量 的 描述 如 下 。 

1) OFF_HEAP 内 存 模 式 : obj 为 null， 地 址 由 64 位 的 offset 唯一 标识 。 

2) ON_HEAP 内 存 模式 : obj 为 堆 中 该 对 象 的 引用 ，offset 对 应 数据 在 该 对 象 中 的 偏 移 量 。 

由 以 上 分 析 可 知 ， 通 过 MemoryLocation 类 可 以 统一 定位 一 个 OFF_HEAP 和 ON_HEAP 两 
种 内 存 模式 下 的 内 存 地 址 。 

对 应 MemoryLocation 类 的 继承 子 类 为 MemoryBlock ， 顾名思义 该 子 类 表示 一 个 内 存 块 3 
无 论 是 OFF_HEAP 还 是 ON_HEAP 内 存 模式 ， 在 Project Tungsten 内 存 管理 时 ， 都 使 用 一 块 连 
续 的 内 存 空间 来 存储 数据 ， 因 此 即使 是 在 ON_HEAP 模式 下 ， 也 可 以 降低 GC 的 开销 。 下 面 
来 看 一 下 MemoryBlock 类 的 注释 信息 ， 具 体 如 下 。 
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1l. 水 

2 x* A consecutive block of memory ,starting at a | @ linkMemoryLocation| with a fixed size. 
3 x* 一 个 连续 的 内 存 块 ,继承 自 描述 内 存 地 址 的 MemoryLocation 类 ,同时 提供 内 存 块 的 
4. * 大 小 

5 */ 

6. 


public classMemoryBlock extends MemoryLocation | 





补充 : 在 代码 复 用 方式 上 存在 两 种 形式 : 继承 与 组 合 。 目 前 ， 在 MemoryBlock 中 使 用 继承 的 方式 包含 内 
存 块 的 地 址 信息 。 在 实现 上 ， 也 可 以 采用 组 合 这 种 复 用 方式 ， 指 定 内 存 块 的 地 址 ， 以 及 内 存 块 本 身 的 
内 存 大 小 。 





下 面 简单 介绍 一 下 MemoryBlock 类 中 除了 继承 自 MemoryLocation 类 之 外 的 部 分 成 员 。 

1) private final long length: 表示 内 存 块 的 长 度 。 

2) public int pageNumber: 表示 内 存 块 对 应 的 page 号 。 

3) public static MemoryBlock fromLongArray (final long [ ] aray): 这 是 提供 的 一 个 将 
long 型 数组 转换 为 MemoryBlock 内 存 块 的 接口 。 

在 提供 了 内 存 块 之 后 ， 下 一 步 就 是 如 何 去 组 织 这 些 内 存 块 ， 在 Project Tungsten 中 采用 了 
类 似 操作 系统 的 内 存 管理 模式 ， 即 使 用 Page Table 方式 来 管理 内 存 。 因 此 ， 下 面 将 对 Page 
Table 管理 方式 进行 解析 。 

4. Project Tungsten 内 存 管理 模型 中 的 内 存 组 织 和 管理 模式 

Spark 是 一 个 技术 框架 ,数据 以 分 区 粒度 进行 处 理 ， 即 每 个 分 区 对 应 一 个 处 理 的 任务 
(Task ) ， 因此 内 存 的 组 织 与 管理 等 可 以 通过 与 Task 一 一 对 应 的 TaskMemoryManager 来 理解 。 

下 面 首 先 给 出 TaskMemoryManager 与 MemoryManager 间 的 关系 图 ， 如 图 8-6 所 示 。 














任务 内 存 管理 内 存 管理 




























存储 内 存 池 
堆 执行 内 存 池 
堆 外 执行 内 存 池 





| 不 安全 内 存 分 配 





图 8-6 TaskMemoryManager 与 MemoryManager 的 关系 


网 
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在 图 8-6 中 ， 各 个 MemoryConsumer 是 具体 处 理 时 需要 使 用 (消耗) 内 存 块 的 实体 ， 
MemoryConsumer 通过 TaskMemoryManager 提供 的 接口 向 MemoryManager 申 请 或 释放 内 存 资 
源 ， 即 申请 或 释放 内 存 块 。TaskMemoryManager 类 中 会 管理 全 部 MemoryConsumer， 并 对 
这 些 内 存 消耗 实体 所 申请 的 内 存 块 进行 组 织 与 管理 ， 具 体 是 通过 PageTable 的 方式 来 O) 











实现 。 


首先 查看 类 的 注释 信息 ， 原 注释 信息 比较 多 ， 





如 下 。 
7 


x* 管理 为 单个 Task 所 分 配 的 内 存 
* 内 存 地 址 在 不 同 的 内 存 模式 下 的 表示 : 








Se ne Po rls 











在 此 仪 给 出 简单 的 中 文 描述 ， 具 体 代 码 


* Manages the memory allocated by an individual task. 


# ”1. OFF_HEAP: 直接 使 用 64 位 表示 内 存 地 址 

* 2. ON_HEAP: 通 过 base object 和 该 对 象 中 64 位 的 偏 移 量 来 表示 

* 通过 封装 类 MemoryBlock 统一 表示 内 存 块 信息 : 

* 1. OFF_HEAP:MemoryBlock 的 base object 为 null, 偏 移 量 对 应 64 位 的 绝对 地 址 














10. ”#* 2. ON_HEAP:MemoryBlock 的 base object 保存 对 象 的 引用 (该 引用 可 以 由 page 的 索引 








从 pageTable 获取 ) 
11. ”* 偏 移 量 对 应 数据 在 该 对 象 中 的 偏 移 量 
12. * 











13. * 通过 这 两 种 内 存 模式 对 应 的 编码 方式 ,最终 对 外 提供 的 编码 格式 为 13bit - pageNumber + 


S1bit — offset 
14. */ 
15. public classTaskMemoryManager | 


下 面 从 3 个 方面 对 TaskMemoryManager 进行 分 析 : 包含 内 存 地 址 的 编码 与 解码 、PageTa- 


ble 的 组 织 与 管理 ， 以 及 内 存 的 分 配 与 释放 。 
(1) 内 存 地 址 的 编码 与 解码 








从 TaskMemoryManager 类 的 注释 部 分 可 以 知道 ，OFF_HEAP 与 ON_HEAP 两 种 内 存 模式 
最 终 对 外 都 是 采用 一 致 的 编码 格式 ， 即 对 应 13 位 的 pageNumber (页 码 ) 和 51 位 的 offset 
( 偏 移 量 ) ， 可 以 通过 图 8-7 来 描述 对 应 的 编码 方式 。 











OFF_HEAP 
内 存 模式 


相对 绝对 地 址 
的 偏 移 量 
(13-bit) (S1-bit) 


图 8-7 ”Page 的 编码 方式 





ON_HEAP 

内 存 模式 
已 有 的 对 象 内 部 

的 偏 移 量 
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下 面 分 别 对 TaskMemoryManager 类 中 与 编码 和 解码 相关 的 几 个 接口 进行 解析 ， 编 码 接口 
主要 有 两 个 ，encodePageNumberAndOffset 和 decodePageNumber 其 源 代码 与 解析 如 下 所 示 。 


1. 
2 
a 
4. 
5. 
6. 
元 
8. 
9. 


王 天王 一 一 于 
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/ ** 
* Given a memory page and offset within that page,encode this address into a 64 — bit long. 
* This address will remain valid as long as the corresponding page has not been freed. 
米 
* @ param page a data page allocated by |@ link TaskMemory Manager#allocatePage|/ 
* @ param offsetInPage an offset in this page which incorporates the base offset. In other 
* words, this should be the value that you would pass as the base offset into an 
* UNSAFE call(e. g. page. baseOffset( ) + something). 
* @ return an encoded page address. 
水 
* 将 针对 某 个 Page 的 地 址 进行 编码 : 
*# ON_HEAP :offsetInPage 是 针对 base object 的 偏 移 量 
* OFF_HEAP; 此 时 ,offsetInPage 是 绝对 地 址 ,因此 编码 到 Page 方式 的 地 址 时 ， 
* 需要 将 绝对 地 址 转换 为 相对 于 已 有 的 Page( MemoryBlock) 中 的 绝对 
* 地 址 offset 的 相对 地 址 。 最 后 将 得 到 的 两 个 偏 移 量 和 Page Number 一 起 组 装 到 13 +51 bits 
的 64 位 中 。 
*/ 
public long encodePageNumberAndOffset( MemoryBlock page, long offsetInPage ) | 
if( tungstenMemoryMode == MemoryMode. OFF_HEAP)| 
// 如 果 是 OFF_HEAP, 则 对 应 的 offsetInPage 为 64 位 的 绝对 地 址 ,需要 转换 为 Page 
// 编 码 能 容纳 的 51 位 编码 中 ,因此 此 时 需要 将 其 转换 为 Page 内 的 相对 地 址 ， 
// 即 页 内 的 偏 移 地 址 





' 














offsetInPage — = page. getBaseOffset( ) ; 
| 


return encodePageNumberAndOffset( page. pageNumber , offsetInPage ) ; 


@ VisibleForTesting 
public static long encodePageNumberAndOffset( intpageNumber, long offsetInPage ) | 
assert( pageNumber | = —1):"encodePageNumberAndOffset called with invalid page" ; 
// 将 13 位 的 页 码 与 51 位 的 页 内 偏 移 量 组 装 成 64 位 的 编码 地 址 
return( ( (long)pageNumber) << OFFSET_BITS) | (offsetInPage & MASK_LONG_LOWER_ 
51_BITS); 
| 





通过 pageNumber 可 以 找到 最 终 的 Page，Page 内 部 会 根据 OFF_HEAP 或 ON_HEAP 两 种 


模式 分 别 存储 Page 对 应 内 存 块 的 起 始 地 址 (或 对 象 内 偏 移 地 址 )， 因 此 编码 后 的 地 址 可 以 遂 
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过 查找 到 Page， 最 终 解码 出 原始 地 址 。 解 码 的 源 代码 及 其 解析 如 下 所 示 。 





Sl 全 认 必 作 汪 用 和 全 人 


呈 











@ VisibleForTesting 
public static intdecodePage Number( long pagePlusOffsetAddress ) | 
// 通 过 13 位 掩 码 解析 出 编码 地 址 中 的 页 码 信 息 , 即 对 应 的 高 13 位 内 容 
return( int) ( (pagePlusOffsetAddress & MASK_LONG_UPPER_13_BITS) >>> OFFSET_BITS); 
| 




















private static longdecodeOffset( long pagePlusOffsetAddress ) | 

// 通 过 51 位 掩 码 解 析出 编码 地 址 中 的 页 码 信息 , 即 对 应 的 低 51 位 内 容 
return( pagePlusOffsetAddress & MASK_LONC_LOWER 51_BITS ) ; 

| 











在 TaskMemoryManager 类 中 还 另外 提供 了 针对 ON_HEAP 内 存 模式 下 获取 base object 的 
接口 ， 对 应 的 源 代码 及 其 解析 如 下 所 示 。 


A A po 


一 一 
DS 


13. 





/ 水 
* Get the page associated with an address encoded by 
* 获取 编码 地 址 相关 的 base object 

* | @linkTaskMemoryManager#encodePageNumberAndOffset( MemoryBlock ,long ) | 

*/ 

public ObjectgetPage(long pagePlusOffsetAddress ) | 

if( tungstenMemoryMode == MemoryMode. ON_HEAP) | 

// 首 先 从 地 址 中 解析 出 页 码 
final intpage Number = decodePageNumber( pagePlusOffsetAddress) ; 
assert( pageNumber >=0 && pageNumber < PAGE_TABLE SIZE); 
// 根 据 页 码 从 pageTable 变量 中 获取 对 应 的 内 存 块 
final MemoryBlock page = pageTable[ pageNumber | ; 








assert( page ! =null); 
assert( page. getBaseObject( ) ! = null); 
// 获 取 内 存 块 对 应 的 BaseObject 


return page. getBaseObject( ) ; 





| else | 
// OFF_HEAP 内 存 模式 下 ,MemoryBlock 只 需要 保存 一 个 绝对 地 址 ,因此 对 应 的 
// base object 为 null 


return null; 


| 


(2) PageTable 的 组 织 与 管理 

在 分 析 这 部 分 内 容 之 前 ， 先 看 一 下 Page Table 方式 进行 组 织 与 管理 描述 图 ， 如 图 8-8 所 示 。 

在 图 8-8 中 ， 右 侧 是 分 配 的 内 存 块 ， 即 当前 需要 管理 的 Page。 在 TaskMemoryManager 
中 ， 通 过 Page Table 来 存放 内 存 块 ， 同 时 ， 通 过 在 变量 allocatedPages 中 指定 值 为 Page Num- 
ber (页 码 ) 的 下 标 (索引 ) 对 应 的 值 是 否 为 1， 来 表示 当前 Page Number 对 应 的 Page Table 
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分 配 的 内 存 块 (页 ) 






页 表 大 小 


页 (1) -内 存 块 
me TT 
页 (2) -内 存 块 





页 表 


马 


页 码 
页 码 (13 位 ) 偏 移 量 (51 位 ) 






页 编码 










相对 绝对 已 有 的 对 象 
地 址 的 偏 移 量 内 部 的 偏 移 量 





堆 外 内 存 模式 堆 内 存 模式 


图 8-8 ”PageTable 组 织 与 管理 描述 图 


中 的 Page 是 否 已 经 存放 了 对 应 的 内 存 块 ， 即 每 当 分 配 到 一 个 内 存 块 时 ， 从 allocatedPages 获 
取 一 个 值 为 0 的 位 置 (页 码 )， 并 将 该 位 置 作为 内 存 块 放 入 到 Page Table 中 的 位 置 。 

简单 来 说 ， 就 是 通过 allocatedPages 中 各 个 位 置 上 的 值 为 1 或 0 来 判断 在 Page Table 中 相 
同位 置 是 否 已 经 放置 了 内 存 块 (Page) 。 

而 对 应 在 Page Table 中 已 经 存放 的 内 存 块 ， 实 际 上 就 是 对 应 了 右 侧 已 经 分 配 的 内 存 块 。 

当 针 对 一 个 Page Encode (页 地 址 编码 ) 时 ， 首 先 从 中 获取 Page Number， 根 据 该 值 从 
Page Table 中 获取 确定 的 内 存 块 (MemoryBlock 或 Page) ， 找 到 确定 内 存 块 之 后 ， 再 通过 页 地 
址 编码 中 的 offset (具体 两 种 内 存 模 式 下 的 概念 如 图 8-8 所 示 ) 确定 内 存 块 中 的 相关 偏 移 
量 。 如 果 是 OFF_HEAP， 则 该 offset 是 相对 于 内 存 块 (从 前 面 分 析 可 知 ， 内 存 块 本 身 的 信息 
也 与 内 存 模式 相关 ) 中 的 绝对 地 址 的 相对 地 址 ; 如 果 是 ON_HEAP， 则 该 offset 是 相对 于 内 
存 块 的 base object 中 的 偏 移 量 。 

相关 的 源 代码 主要 涉及 TaskMemoryManager 类 的 两 个 成 员 变量 ， 如 下 所 示 。 











// 对 应 图 8-8 中 的 Page Table 
private final MemoryBlock|[ | pageTable = new MemoryBlock[ PAGE_TABLE_SIZE |; 





// 对 应 图 8-8 中 的 allocatedPages 
private final BitSet allocatedPages = new BitSet( PAGE_TABLE_SIZE); 





1 
之 
3 
4 
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PageTable 的 组 织 与 管理 中 关于 页 码 的 偏 移 量 已 经 在 上 一 部 分 给 出 了 详细 描述 ， 而 对 应 
的 具体 管理 操作 则 与 实际 的 内 存 分 配 与 解析 部 分 相关 。 通 过 图 8-8 对 大 致 的 管理 有 一 定 的 
概念 后 ， 再 继续 通过 内 存 分 配 与 解析 部 分 来 详细 解析 具体 的 管理 细节 。 

(3) 内 存 分 配 与 解析 

关于 这 部 分 内 容 ， 主 要 参考 allocatePage 与 freePage 两 个 方法 ， 对 应 allocatePage 内 部 如 

















acquireExecutionMemory 的 具体 源 代 码 来 加 深 理 解 。 
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何 申请 内 存 ， 以 及 申请 内 存 时 采用 的 spill 策略 等 细节 ， 大 家 可 以 继续 深入 ， 比 如 通过 查看 








allocatePage 方法 的 源 代码 及 其 解析 如 下 所 示 。 
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* Allocate a block of memory that will be tracked in theMemoryManager! s page table;this 


* is intended for allocating large blocks of Tungsten memory that will be shared between 


* Operators. 


* Returns ‘hull if there was not enough memory to allocate the page. May return a page 


* that contains fewer bytes than requested ,so callers should verify the size of returned 


* pages. 








* 分 配 一 块 内 存 , 并 通过 MemoryManager( 实际 上 是 在 TaskMemoryManager 中 ) 的 
x* Page Table 进行 跟踪 ;分 配 的 是 Execution 部 分 的 内 存 
x* Project Tungsten 的 内 存 包 含 OFF_HEAP 和 ON_HEAP 两 种 模式 ,由 底层 





* tungstenMemoryMode( 在 MemoryManager 
MemoryAllocator 子 类 
*/ 


P 设 置 ) 控 制 具体 分 配 的 


public MemoryBlock allocatePage( long size, MemoryConsumer consumer ) | 


// 页 大 小 的 限制 
if(size > MAXIMUM_PAGE_SIZE_BYTES) 


throw new IllegalArgumentException( 


| 


"Cannot allocate a page with more than" + MAXIMUM_ PAGE SIZE_ BYTES + "bytes" ); 


// 特 定 的 内 存 消费 者 consumer 以 指定 的 
// 申 请 一 定 的 内 存量 


ul 





内 存 模式 tungstenMemoryMode 


long acquired = acquireExecutionMemory( size ,tungsten MemoryMode ,consumer ) ; 


if(acquired <=0)| 


return nul] ; 


final intpageNumber; 


synchronized(this ) | 
// 获 取 当 前 未 被 占用 的 页 码 





pageNumber = allocatedPages. nextClearBit( 0 ) ; 


if( pageNumber >= PAGE_TABLE_SIZE) 


| 


releaseExecutionMemory( acquired ,tungstenMemoryMode , consumer ) ; 


throw new lllegalStateException( 


" Have already allocated a maximum 


| 














of " + PAGE_TABLE_SIZE + " pages" ) ; 


// 设 置 该 页 码 已 经 被 占用 ( 即 设置 对 应 页 码 位 置 的 值 ) 























allocatedPages. set( page Number) ; 
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39. } 

40. 

41. // 开 始 通 过 MemoryAllocator 真正 分 配 内 存 

42. // 注 意 :acquireExecutionMemory 中 通过 ExecutionMemoryPool 进行 分 配 时 ， 

43. // 仪 仅 是 内 存 使 用 大 小 上 的 控制 ,并 没有 真正 分 配 内 存 

44. // 有 兴趣 的 话 , 可 以 查看 对 acquireExecutionMemory 的 调用 点 (其 中 

45. // 可 以 指定 与 tungstenMemoryMode 不 同 的 其 他 内 存 模 式 ， 

46. // 此 时 是 不 存在 真正 的 内 存 分 配 的 ) 

47. finalMemoryBlock page = memoryManager. tungstenMemoryAllocator( ). allocate( acquired ) ; 
48. 

49. // 分 配 得 到 内 存 块 之 后 ,会 设置 该 内 存 块 对 应 的 pageNumber， 

50. // 即 此 时 设置 MemoryBlock 在 其 管理 的 Page Table 中 的 位 置 

Sk page. page Number = page Number:; 

S22 pageTable[ page Number | = page; 

53. if( logger. isTraceEnabled( ) ) | 

54. logger. trace( " Allocate page number | (| bytes)" ,pageNumber,acquired); 
55. } 

56. return page; 

5 } 





其 中 ，MAXIMUM_PAGE_SIZE_BYTES 是 页 内 数据 量 大 小 的 限制 ， 从 之 前 MemoryBlock 











提供 





的 从 long 型 数组 转换 得 到 MemoryBlock 接口 ， 可 以 知道 当前 连续 的 内 存 块 是 通过 long 型 


数组 来 获取 的 ， 因 此 对 应 的 内 存 块 的 大 小 也 会 受到 数组 的 最 大 长 度 的 限制 。 





至 于 对 应 在 具体 的 处 理 过 程 中 ， 对 页 内 的 数据 量 大 小 是 否 还 有 其 他 限制 ， 可 以 参考 具体 





的 处 理 细节 ， 下 一 节 会 给 出 一 个 具体 处 理 过 程 的 源 代码 解析 ， 其 中 会 包含 这 部 分 内 容 。 





由 于 内 存 分 配 的 细节 比较 多 ， 这 里 给 出 主要 的 过 程 描述 。 
1) 首先 通过 acquireExecutionMemory 方法 向 ExecutionMemoryPool 申请 内 存 (根据 统一 








或 静态 两 种 具体 实现 给 出 ) : 这 一 部 分 主要 是 判断 当前 可 用 的 内 存 是 否 满足 申请 需求 ， 并 根 
据 申 请 结果 修改 当前 内 存 池 可 用 的 内 存 信 息 (实际 是 当前 使 用 内 存量 信息 )。 























2) 从 当前 Page Table 中 找 出 一 个 可 用 位 置 ， 用 于 存放 所 申请 的 内 存 块 ( MemoryBlock 


或 Page) 。 





3) 准备 好 前 两 步 后 ， 开 始 通过 MemoryAllocator 真正 分 区 内 存 块 。 
4) 将 分 配 的 内 存 块 放 入 Page Table。 
在 整个 过 程 中 ，allocatedPages 与 pageTable 这 两 个 成 员 变 量 的 使 用 是 体现 Page Table 组 














织 与 管理 的 关键 所 在 。 





下 面 解析 freePage 的 源 代码 ， 如 下 所 示 。 





上 A 沙洲 
2 * Free a block of memory allocated via |@ linkTask MemoryManager#allocatePage|. 
3. * 更 新 Page Table 相关 信息 ,通过 MemoryAllocator 释放 Page 的 内 存 ， 
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4 x* 最 后 通过 MemoryManager 修改 ExecutorManagerPool 中 的 内 存 使 用 量 ( 即 释放 ) 
S */ 

6. public void freePage( MemoryBlock page, MemoryConsumer consumer) | 

7 // 首 先 确 认 当 前 释放 的 内 存 块 位 Page Table 的 管理 中 , 即 页 码 必 须 有 效 O) 
8 assert( page. pageNumber | = -1) : 

9 "CalledfreePage( )on memory that wasn t allocated with allocatePage( )"; 

10. assert( allocatedPages. get( page. pageNumber) ) ; 

11. pageTable[ page. pageNumber | = null; 

| 

13. //allocatedPages 是 控制 pageTable 中 对 应 位 置 是 否 可 用 的 ， 

14. // 需 要 考虑 释放 与 分 配 时 的 并 发 性 ,因此 需要 同步 处 理 

3; synchronized(this ) | 

16. allocatedPages. clear( page. pageNumber) ; 

[9 } 

18. if( logger. isTraceEnabled( ) ) | 

19. logger. trace( " Freed page number | | (|| bytes)" ,page. pageNumber, page. size( ) ) ; 
20. } 

下 

224 // 通 过 当前 内 存 模 式 对 应 的 MemoryAllocator 真正 释放 该 内 存 块 

233 long pageSize = page. size( ) ; 

24. memoryManager. tungsten MemoryAllocator( ). free( page); 

2 

26. // 对 应 ExecutionMemoryPool 部 分 的 内 存 释 放 ， 

278 // 参 考 前 面 acquireExecutionMemory 解析 一 起 了 解 

28. releaseExecutionMemory( pageSize ,tungsten MemoryMode ,consumer ) ; 

2 } 








释放 Page 的 逻辑 实际 上 可 以 参考 申请 Page， 大 部 分 都 是 步骤 相反 而 已 。 





; | 基于 内 存 管理 模型 的 Shuffle 二 进 制 数据 处 理 















































就 目前 来 说 ，Project Tungsten 的 二 进 制 数据 处 理 主 要 是 用 在 Shuffle 和 SQL 的 aggregation 
(聚合 ) (以 及 其 他 一 些 操作 ) 数据 上 ， 像 为 其 他 非 JVM 的 本 地 类 库 (如 C++ 类 库 ) 等 提供 
内 存 访 问 等 操作 ， 仍 然 还 在 实现 中 (有 兴趣 的 读者 可 以 参考 https://issues. apache. org/jirav/ 
browse/SPARK -10399 部 分 ) 。 

本 书 基于 Shuffle 过 程 ， 解 析 在 源 代 码 中 具体 如 何 使 用 Project Tungsten 来 处 理 数 据 ， 对 
应 其 他 操作 的 处 理 细节 ， 可 以 参考 对 应 issues 及 其 设计 文档 (部 分 提供 了 非常 详细 的 设计 文 
档 ) 。 比 如 在 聚合 方面 使 用 Project Tungsten 内 存 模 型 的 详细 设计 可 以 参考 https:// 
issues. apache. org/jira/browse/SPARK -7080， 对 应 的 设计 文档 为 https://github. com/apache/ 
spark/pull/S$725。 读 者 可 以 基于 这 些 设计 文档 ， 然 后 参考 本 节 的 源 代码 解析 过 程 来 加 深 理 解 。 
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在 7.5 Tungsten Sorted Based Shuffle 一 节 写 数据 的 源 代码 解析 中 已 经 提 到 ， 在 写 数据 时 
会 使 用 一 个 外 部 排序 器 ShuffleExternalSorter 对 Shuffle 数据 进行 排序 5 该 外 部 排序 器 中 的 数据 
处 理 就 是 建立 在 Project Tungsten 内 存 模型 基础 之 上 的 。 因 此 本 节 继 续 深 入 解析 Shuffle 写 数 














据 的 过 程 9 从 Project Tungsten 内 存 模 型 的 使 用 角 度 来 结合 源 代 码 进行 解析 。 

首先 ， 从 前 面 对 TaskMemoryManager 的 源 代码 解析 可 以 知道 ， 所 有 内 存 申 请 与 释放 的 请 
求 都 是 通过 MemoryConsumer 来 提交 的 ， 因 此 首先 需要 了 解 在 Shuffle 的 写 过 程 中 ， 外 部 排序 
全 ShuffleExternalSorter 与 内 存 消费 者 MemoryConsumer 之 间 的 关系 。 为 了 了 解 这 一 点 ， 可 以 
先 查 看 ShuffleExternalSorter 类 的 注释 与 类 定义 ， 具 体 源 代码 如 下 。 













































































1l. 水 

2 * An external sorter that is specialized for sort — based shuffle. 

3 * <p> 

4. * Incoming records are appended to data pages. When all records have been inserted( or 

5. * When the current thread s shuffle memory limit is reached) ,the in ~ memory records are 

6. * sorted according to their partition ids(using a |@ link ShuffleInMemorySorter} ). The 

7 # sorted records are then written to a single output file(or multiple files,if we ve spilled). The 
8. * format of the output files is the same as the format of the final output file written by 

9. * | @ link org. apache. spark. shuffle. sort SortShuffleWriter| :each output partition s records are 
10. * written as a single serialized,compressed stream that can be read with a new 

ll.  * decompression anddeserialization stream. 

2 > 

13. x* Unlike | @ link org. apache. spark. util. collection. ExternalSorter| ,this sorter does not merge 
14. x* its spill files. Instead,this merging is performed in {|@ linkUnsafeShuffleWriter| ,which 

15.  * uses a specialized merge procedure that avoids extra serialization/ deserialization. 

16. * 

17. * 为 sort - base Shuffle 定制 的 外 部 排序 器 

18. = 输入 的 记录 会 附加 到 数据 pages 中 。 当 所 有 的 数据 搬入 后 (或 当前 线程 分 配 的 

19.， * Shuffle 内 存 达到 极限 时 ) ,内 存 中 (in - memory) 的 记录 会 根据 分 区 ID 进行 排序 (使 

20. ”# 用 ShuffleIfnMemorySorter) 。 排 序 后 的 记录 会 写 人 一 个 输出 文件 (或 多 个 文件 ,如 

21. * 困 发 生 spilled 的 话 ) 。 输 出 文件 的 格式 与 SortShuffleWriter 的 输出 文件 个 数 相同 : 

22. * 每 个 输出 的 分 区 记录 通过 一 个 序列 化 的 .压缩 的 流 写 入 。 之 后 再 使 用 解压 的 \ 反 序列 
23. ”* 化 的 流 进行 读 取 

24. ”与 ExternalSorter 不 同 ,ExternalSorter 排序 器 不 会 进行 spill 文件 的 合并 。 

25.， * 而 ShuffleExternalSorter 排序 器 在 最 后 会 进行 合并 ,使 用 一 个 可 以 避免 序列 化 / 反 序 列 
26. + 化 的 特定 的 合并 过 程 

27. * ShuffleExternalSorter 继承 了 MemoryConsumer, 会 向 TaskMemoryManager 申请 / 释 

28. * 放 Execution 内 存 

2 办 

30. final class ShuffleExternalSorter extendsMemoryConsumer | 


可 以 看 到 ，ShuffleExternalSorter 继承 了 MemoryConsumer， 此 在 数据 人 处理 时 可 以 向 
TaskMemoryManager 申请 /释放 Execution 内 存 。 
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对 应 的 ， 其 他 建立 在 Project Tungsten 内 存 模型 基础 上 的 数据 处 理 也 可 以 通过 查看 Memo- 
ryConsumer 的 子 类 来 获取 ， 比 如 前 面 SPARK - 7080 提 到 的 设计 文档 中 的 BytesToBytesMap 
子 类 。 

在 详细 解析 源 代码 之 前 ， 同 样 先 给 出 ShuffleExtemalSorter 在 内 存 处 理 上 的 流程 ,如 他) 
图 8-9 所 示 。 

步骤 如 下 。 

1) 首先 是 插入 记录 ， 由 UnsafeShuffleWriter 调用 ShuffleExternalSorter 的 insertRecord 方 
法 ， 向 currentPage 插入 一 条 记录 ， 即 图 8-9 中 的 第 1 步 insertRecord。 

2) 此 时 ， 如 果 当 前 页 内 存 未 分 配 ， 或 剩余 空间 不 足以 容纳 记录 数据 ， 则 向 TaskMemo- 
ryManager 申请 内 存 ， 即 图 8-9 中 的 第 2 步 allocatePage。 

3) 在 申请 内 存 时 ， 有 可 能 由 于 内 存 压 力 而 发 出 MemoryConsumer ( 即 这 里 的 ShuffleEx- 
ternalSorter) 的 spil 操作 ， 即 图 8-9 中 的 第 3 步 spill。 

4) 触发 spill 操作 时 ， 会 获取 ShuffleInMemorySorter 的 排序 数据 的 迭代 器 ， 将 排序 后 的 
数据 spill 到 文件 中 ， 即 图 8-9 中 的 第 8 步 getSortedIterator; 同时 再 会 释放 ShuffleExternalSorter 
占用 的 内 存 (通过 由 记录 的 内 存 页 allocatedPages 实现 ) ， 即 图 8-9 中 的 第 4 步 freePage。 


1、 插 入 记录 3/7. 内 存 溢 出 






























ShuffleExternalSorter 2. 分 配 页 
4. 释放 页 





和 
1 分 配 页 


ShuffleInMemorySorter 


图 8-9 ShuffleFxternalSorter 处 理 流 程 图 





5) 当 currentPage 能 够 容纳 记录 数据 时 ， 将 数据 插入 到 内 存 页 中 ， 同 时 会 将 记录 的 编码 
地 址 插入 到 ShufflefnMemorySorter 的 LongArray 中 ， 即 图 8-9 中 的 第 5 步 insertRecord 。 

6) 插入 编码 的 地 址 过 程 中 ， 也 可 能 会 由 于 LongArray 内 存 不 足 而 向 TaskMemoryManager 
申请 内 存 ， 即 图 8-9 中 的 第 6 步 allocatePage。 申 请 过 程 中 也 可 能 会 触发 sp 记 ， 这 和 前 面 内 存 
申请 时 描述 的 过 程 一 样 。 

7) 最 后 ， 在 完成 记录 插入 后 也 会 调用 第 8 步 的 getSortedIterator， 获 取 在 ShuffleInMemo- 
rySorter 的 LongArray 中 未 spill 到 文件 的 内 存 数据 ， 然 后 写 和 人 最 后 一 个 文件 (所 以 这 个 文件 
写 入 的 数据 量 不 作为 spill 的 Metric 度量 信息 ) 。 

在 整个 处 理 流程 中 ， 比 较 难 以 理解 的 是 数据 或 地 址 在 内 存 中 的 存储 与 处 理 (实际 是 用 
与 存储 相反 的 过 程 来 读 取 数 据 进行 处 理 ， 所 以 本 质 上 还 是 理解 数据 是 以 何 种 方式 在 和 内存 
页 的 ) 。 



































内 核 机 制 解析 及 性 能 调 优 











ShuffleExternalSorter 类 的 内 部 处 理 过 程 ， 可 以 先 从 该 类 在 UnsafeShuffleWriter 中 的 使 用 开 
始 去 理解 。 如 果 已 经 熟悉 了 UnsafeShuffleWriter 的 大 致 的 写 数 据 过 程 ， 可 以 直接 忽略 ， 如 果 
不 熟悉 ， 也 可 以 简单 地 在 UnsafeShuffleWriter 类 中 搜索 ShuffleExternalSorter 类 的 调用 点 来 获 
取 二 进 制 处 理 的 入 口 。 

下 面 直接 从 ShuffleExternalSorter 类 基于 Project Tungsten 内 存 模 型 处 理 数据 的 关键 入 口 点 
开始 解析 插入 记录 (对 应 ShuffleExternalSorter 的 在 UnsafeShuffleWriter 类 的 open 与 stop 方法 
中 的 处 理 可 以 暂时 忽略 ) ， 也 就 是 图 8-9 中 的 第 1 步 插 入 记录 (insertRecord)。 即 从 Unsafe- 
ShuffleWriter 的 ipsertRecordIntoSorter 方法 中 的 相关 源 代码 部 分 开始 ， 简 单 源 代码 如 下 。 

















void insertRecordIntoSorter( Product2 < K,V > record ) throwsIOException | 


1 

之 

3 sorter. insertRecord ( 

4 serBuffer. getBuf( ) ,Platform. BYTE_ARRAY_OFFSET ,serializedRecordSize , partitionld ) ; 


| 








其 中 第 3 ~ 5 行 是 解析 的 关键 入 口 点 ， 也 就 是 ShuffleExternalSorter 的 insertRecord 方法 。 
在 该 方法 中 会 把 当前 的 serBuffer 内 容 ( 即 一 条 记录 数据 ) 插入 到 ShuffleExternalSorter 中 。 
此 ， 接 下 来 首先 分 析 insertRecord 方法 ， 对 应 源 代 人 码 及 其 解析 如 下 。 
































1. /六 六 

2 * Write a record to the shuffle sorter. 

3. * 向 Shuffle 排序 器 写 人 一 条 记录 

4. */ 

3 public void insertRecord( Object recordBase ,long recordOffset, int length ,int partitionId ) 
6. throwsIOException | 

9 

8. 

9. // 如 果 需 要 的 话 ,增加 内 存 中 排序 所 需 的 LongArray 内 存 大 小 

10. growPointerArrayIfNecessary( ) ; 

i // Need 4 bytes to store the record length. 

1 /记录 搬入 时 ,以 记录 长 度 作 为 起 始 信息 ,然后 是 对 应 该 长 度 的 记录 数据 
13. 人/ 因此 申请 的 内 存 大 小 需要 考虑 长 度 本 身 所 占 的 4 个 字 节 

14. final int required = length +4; 

15, acquireNewPagelfNecessary ( required ) ; 

16. 

1 assert( currentPage ! = null); 

18. // 获 取 当 前 页 的 base object 

19. final Object base = currentPage. getBaseObject( ) ; 

20. 

2 // 针 对 currentPage 内 的 页 游标 ( 当前 起 始 地 址 ) 进行 编码 

22. // 该 地 址 对 应 该 记录 的 起 始 地 址 (格式 :4 字 闻 的 长 度 + 记录 数据 ) 
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2 final longrecordAddress = taskMemoryManager. encodePageNumberAndOffset ( currentPage, 
pageCursor ) ; 

24. 

2 // 首 先 将 记录 的 长 度 (Int,4 字 节 ) 放 和 人 base + pageCursor 对 应 的 内 存 地 址 ， O) 

26. // 更 新 当前 页 内 地 址 pageCursor 

2 Platform. putInt( base ,pageCursor ,length ) ; 

28. pageCursor +=4; 

29. 

30. // 将 记录 数据 recordBase +recordOffset 复制 到 base + pageCursor( 已 更 新 4 字 节 ) 

31. // 中 ,长 度 为 记录 长 度 , 更 新 当前 页 内 地 址 pageCursor 

2 Platform. copyMemory ( recordBase ,recordOffset ,base,pageCursor ,length ) ; 

998 pageCursor += length; 

34. 

35. // 将 记录 的 编码 地 址 (PageNumber + 页 内 Offset) 及 其 分 区 号 插入 到 

36. /内存 排 序 器 中 

27 inMemSorter. insertRecord(recordAddress ,partitionId ) ; 

38. } 








处 理 的 大 致 流程 在 前 面 已 经 给 出 简单 描述 ， 这 里 主要 分 析 记 录 是 如 何 存 储 在 内 存 页 
(Page) 的 ， 即 内 存 页 中 记录 的 组 织 形式 ， 可 以 通过 图 8-10 来 描述 。 



































条 记录 的 表示 形式 一 条 记录 在 内 存 页 中 的 存储 





recordBase 汀 弦 萨 
a 记录 的 数据 
| length) 
= | 


recordOffset 








图 8-10 ”内 存 页 中 记录 的 组 织 形式 





将 记录 存 人 内 存 页 时 ， 首 先是 在 内 存 页 当前 游标 (pageCursor) 所 在 位 置 存放 该 记录 的 
数据 长 度 (长 度 long 类 型 对 应 4 字 节 ， 因 此 占用 的 空间 是 记录 数据 的 长 度 +4 字 节 ) ， 然 后 
通过 描述 记录 数据 信息 的 三 元 素 ， 将 记录 数据 复制 到 数据 长 度 后 面 的 内 存 页 空间 中 。 

描述 记录 数据 信息 的 三 元 素 如 下 。 

1) recordBase: 记录 所 在 的 对 象 。 

2) recordOffset: 记录 在 对 象 中 的 偏 移 量 。 

3) length: 记录 数据 的 长 度 。 
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在 处 理 过 程 中 ， 通 过 TaskMemoryManager 的 encodePageNumberAndOffset 方法 ， 将 记录 在 





内 存 页 中 的 存储 地 址 进行 编码 (存储 时 已 经 包含 记录 的 长 度 和 数据 ， 因 此 只 需要 起 始 地 址 
即 可 ) ， 并 将 该 编码 地 址 和 所 在 分 区 ID 一 起 搬入 到 inMemSorter (ShufflefnMemorySorter) 变 
量 中 。 继 续 查 看 插入 的 信息 是 如 何在 ShufflefnMemorySorter 中 组 织 的 ， 具 体 源 代码 如 下 。 











public void insertRecord( long recordPointer ,int partitionId ) | 
if( ! hasSpaceForAnotherRecord( ) ) | 


expandPointerArray( consumer. allocateArray(array. size( ) *2) ) ; 


| 


1 
之 
3 
4 
5. 
6 // 以 PackedRecordPointer 封装 记录 数据 的 编码 地 址 ， 

// 编 码 格式 为 :24bit - Partitionld + 13bit - PageNumber + 27bit - offset 

8 // 说 明 :amay 对 应 的 元 素 为 Long 类 型 ,因此 长 度 为 64bit 

9 array. set( pos, PackedRecordPointer. packPointer( recordPointer ,partitionId ) ) ; 


10. pos ++ ; 
11. } 


在 插入 到 ShufflefnMemorySorter 时 ， 会 将 信息 重新 封装 为 PackedRecordPointer， 然 后 存放 
到 LongArray 中 。 下 面 首先 给 出 一 个 示意 图 ， 如 图 8-11 所 示 。 


记录 指针 





页 码 (13 位 ) | 偏 移 量 (51 位 ) 





封装 记录 指针 





区 ID 号 (24 位 ) 页 码 (13 位 ) 偏 移 量 (27 位 ) 





图 8-11 PackedRecordPointer 封装 示意 图 


最 终 将 记录 的 编码 地 址 recordPointer 通过 PackedRecordPointer 包装 成 一 个 64 位 的 long 
型 地 址 。 即 在 ShufflefnMemorySorter 的 LongArray 中 存放 的 是 重新 包装 后 的 地 址 ， 从 该 地 址 可 
以 看 到 ， 地 址 中 包含 了 分 区 ID 信息 PartitionId ， 该 信息 是 用 于 记录 排序 的 。 对 应 的 页 内 偏 移 
量 也 缩 成 了 27 位 ， 因 此 在 使 用 Project Tungsten 内 存 模 型 时 ， 记 录 的 长 度 也 从 原先 的 2” -1 
变 成 了 2”-1 ( 即 当 记 录 长 度 超过 该 值 时 ， 无 法 使 用 基于 Tungsten 的 Shuffle 机 制 ) 。 同 样 ， 
使 用 时 分 区 的 数量 也 会 受到 限制 ， 即 只 能 有 2”- 1 个 分 区 。 

对 应 在 插入 数据 的 过 程 中 ， 使 用 的 两 个 方法 在 某 些 细 节 上 可 能 不 容易 理解 ， 因 此 这 里 也 
给 出 简单 的 源 代 码 及 其 解析 。 

首先 是 growPointerArrayIfNecessary 方法 ， 具 体 代 码 如 下 。 























I private void growPointerArrayIfNecessary( ) throwsIOException | 
外 assert( inMemSorter | =null ) ; 
于 if(! inMemSorter. hasSpaceForAnotherRecord( ) ) | 








A po 
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long used = in MemSorter. getMemoryUsage( ) ; 
LongArray array; 
try | 
// could trigger spilling O) 
// 内 部 会 通过 TaskMemoryManager 的 allocatePage 方法 申请 内 存 ， 
// 在 申请 时 遇 到 内 存 不 足 会 采用 一 定 的 策略 进行 spill 
array = allocateArray(used / 8 * 2); 
|} catch( OutOfMemoryError e) | 





// should have trigger spilling 

assert( inMemSorter. hasSpaceForAnotherRecord( ) ) ; 

return; 
| 
// check if spilling is triggered or not 
// 如 果 在 申请 内 存 过 程 中 触发 了 sp 记 ,使 得 inMemSorter 有 空间 容纳 男 一 条 记录 ， 
// 则 释放 刚 申 请 的 array (LongArray 内 部 组 合 了 申请 的 内 存 块 MemoryBlock ) 
if(inMemSorter hasSpaceForAnotherRecord( ) ) | 


freeArray(array ) ; 


























| else | 
// 如 果 没 有 触发 spill, 则 inMemSorter 使 用 新 的 array( 内 部 会 有 旧 数 据 的 迁移 ) 


inMemSorter. expandPointerArray( array) ; 








| 


acquireNewPagelfNecessary 方法 ， 具 体 代 码 如 下 。 

















/4** 为 了 插入 一 些 新 的 记录 而 申请 更 多 的 内 存 
* 会 从 内 存 管理 处 申请 所 需 的 内 存 ,并 在 申请 失败 时 触发 sp 记 
光 54 














private void acquireNewPagelfNecessary( int required ) | 
// 当 初始 情况 或 当前 页 (currentPage) 剩余 空间 不 足以 容易 所 要 求 的 大 小 时 ， 
/7 申请 新 的 内 存 页 ,并 更 新 当前 页 的 游标 (指向 当前 页 中 可 用 内 存 的 起 始 位 置 )， 
// 同 时 将 当前 内 存 也 放 入 allocatedPages, 以 便 后 续 spil 或 stop 等 情况 下 释放 全 部 页 
内 存 


if( currentPage == null | 1 



























































pageCursor + required > currentPage. getBaseOffset( ) + currentPage. size( ) ) | 
// TODO .try to find space in previous pages 

currentPage = allocatePage( required ) ; 

pageCursor = currentPage. getBaseOffset( ) ; 

allocatedPages. add( currentPage ) ; 
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可 以 将 继承 MemoryConsumer 类 的 子 类 作为 二 进 制 解析 数据 的 关键 入口 点 ， 从 前 面 对 
TaskMemoryManager 类 的 解析 源 代 码 中 已 经 知道 ， 当 内 存 不 足 时 ， 会 采用 某 种 策略 调用 Mem- 
oryConsumer 的 sp 记 方法 (对 应 策略 比较 简单 ， 可 以 直接 参考 源 代 码 ) ， 因 此 ，spil 方法 也 
是 理解 ShuffleExternalSorter 类 内 部 处 理 过 程 的 一 个 关键 入 口 点 。 也 就 是 图 8-9 中 的 第 3 步 和 
第 7 步 spill。 

下 面 是 spill 的 关键 代码 及 其 解析 。 


























1. ] 水 米 

2 * Sort and spill the current records in response to memory pressure. 
3. * 在 内 存 压力 下 ,排序 并 spill 当前 记录 和 集 

4. */ 

S @ Override 

6. public long spill( long size, MemoryConsumer trigger) throws IOException | 
A 

8. writeSortedFile(false ) ; 

9. 

10. //writeSortedFile 不 会 释放 内 存 ,因此 需要 手动 释放 

11. final longspillSize = freeMemory( ) ; 

六 taskContext. task Metrics( ). ineMemoryBytesSpilled( spillSize ) ; 
13. return spillSize; 

14. | 


在 spill 时 就 会 调用 writeSortedFile 方法 (记录 集 人 处理 完成 后 也 会 调用 ， 只 是 参数 不 同 )， 
之 后 便 释放 占用 的 全 部 内 存 。 对 应 writeSortedFile 方法 的 解析 ， 在 理解 了 记录 在 内 存 页 中 存 
储 的 组 织 形式 之 后 ， 相 对 比较 好 理解 ， 因 此 这 里 仅 给 出 该 方法 的 注释 信息 ， 具 体 代码 如 下 。 











/六 六 

* Sorts the in ~ memory records and writes the sorted records to an on — disk file. 

* This method does not free the sort data structures. 

* 

* @ param isLastFile if true ,this indicates that we re writing the final output file and that 
* _ the bytes written should be counted towards shuffle spill metrics 


* rather than shuffle write metrics. 
水 


* 在 内 存 中 对 记录 进行 排序 ,并 写 入 磁盘 的 一 个 文件 中 

* 该 方法 并 不 会 释放 排序 的 数据 结构 ( 即 需要 手动 释放 内 存 ) 
x* 当 isLastFile 为 : 
12. *# ”1. true 时 ,表示 最 后 一 个 输出 文件 ,此 时 写 的 数据 量 统计 在 Shuffle write 的 度量 信息 中 
ja x* ”2.false 时 , 则 同时 统计 在 Shuffle write 和 Shuffle spill 的 度量 信息 中 

14. */ 

15. private void writeSortedFile( boolean isLastFile ) throws IOException | 


2001 














2 





到 
pe 
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至 此 ， 基 本 上 解析 了 基于 Project Tungsten 内 存 模型 的 整个 Shuffle 数据 处 理 过 程 ， 作 为 扩 
展 ， 下 面 简单 描述 一 下 内 存 中 的 排序 (对 应 ShufflefnMemorySorter 类 )， 排 序 时 主要 使 用 了 
TimSort 排序 算法 (封装 Java 上 的 实现 ) ， 所 采用 的 比较 器 为 SortComparator， 对 应 的 定义 如 下 。 





private static final classSortComparator implements Comparator < PackedRecordPointer > | 
@ Override 
public int compare( PackedRecordPointer left, PackedRecordPointer right) | 
return left. getPartitionId( ) — right. getPartitionId( ) ; 
| 
| 


从 源 代 码 中 可 以 看 到 ， 比 较 时 ， 使 用 的 是 PackedRecordPointer 对 象 中 的 分 区 有， 所 以 
在 基于 Tungsten 的 Shuffle 机 制 中 ， 记 录 是 按 分 区 ID 进行 排序 ， 并 没有 对 分 区 内 部 的 记录 进 
行 排 序 。 

基于 Project Tungsten 内 存 模 型 的 数据 处 理 ， 从 MemoryConsumer 角度 出 发 (包含 那些 内 
部 使 用 了 MemoryConsumer 的 类 ， 如 UnsafeExternalSorter) ， 逐 个 去 理解 内 部 的 数据 结构 组 织 
与 二 进 制 数据 处 理 等 方式 。 


A am 








[说明 ; 通常 在 代码 中 ， 有 open 方法 的 话 ， 也 会 同时 对 应 有 stop 方法 ， 就 像 资 源 有 申请 同时 也 会 有 释放 ， 
或 者 元 数据 信息 有 创建 也 会 有 销毁 一 样 。 这 些 配对 的 处 理 方 式 可 以 在 阅读 源 代 码 时 注意 一 下 ， 笔 者 在 
源 代码 解析 时 可 能 不 会 过 于 强调 这 点 ， 但 实际 上 这 点 是 很 重要 的 。 











Bd 


本 章 内 容 的 主 则 在 于 抛砖引玉 ， 在 结合 Databricks 公司 发 布 的 博文 和 Spark issues 及 其 相 
关 的 设计 文档 的 基础 上 ， 从 源 代码 角度 对 目前 已 经 实现 的 部 分 Project Tungsten 进行 解析 ， 主 
要 内 容 包 含 Project Tungsten 的 内 存 模 型 ， 以 及 在 该 内 存 模型 基础 上 ， 以 Shuffle 写 数 据 的 过 
程 为 例 ， 详 细 解 析 在 Project Tungsten 的 内 存 模型 上 对 数据 结构 进行 组 织 ， 以 及 基于 二 进 制 处 
理 数 据 等 方面 的 内 容 。 


























Su 
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第 9 曹 性 能 优化 





Spark 自 诞生 以 来 ， 高 效 极致 的 运算 性 能 就 一 直 是 其 不 懈 的 追求 ， 如 何 写 出 高 效 的 程 
序 ， 合理 地 配置 参数 ， 并 针对 执行 过 程 中 的 问题 做 出 性 能 诊断 和 优化 ， 也 是 Spark 高 手 必须 
掌握 的 知识 。 本 章 首先 讲解 Spark 的 配置 机 制 ， 然 后 讲解 如 何 通 过 查看 程序 运行 时 的 细节 信 
息 来 进行 性 能 诊断 ， 最 后 讲解 常见 的 spark 性 能 优化 的 方法 。 














9 Spark 的 配置 机 制 


Spark 默认 的 配置 是 为 了 能 让 Spark 在 大 多 数 集群 ， 包 括 那 些 配 置 比较 低 的 集群 上 运行 
起 来 ， 所 以 显然 默认 的 配置 不 一 定 适合 特定 用 户 的 集群 ， 不 一 定 能 够 最 大 化 地 使 用 集群 次 
源 ， 因 此 和 需要 针对 自己 的 集群 状况 ， 对 一 些 配置 做 出 优化 调整 。 


9.11 匡 开 SparkConf 配置 Spark ) 


常见 的 配置 方式 是 在 程序 中 通过 SparkConf 来 进行 配置 。SparkConf 包含 一 系列 key/value 
对 用 来 覆盖 默认 的 配置 。 在 使 用 时 ， 只 需要 实例 化 SparkConf， 然 后 调用 它 的 set( ) 方 法 来 设 
置 具体 配置 项 。 

一 个 简单 的 实例 代码 如 下 。 















































1 object WordCount | 

2 def main( args: Array[ String | ) | 

3 // 实 例 化 SparkConf 

4. val conf = new SparkConf( ) 

5. // 设 置 程序 名 称 

0 conf. set( "spark. app. name" ," My Spark App" ) 
7 // 设 置 master 

8. conf. set( " spark. master" ," local[ 4]") 
9. // 设 置 port 

10. conf set( " spark. ui. port" ,"36000" ) 
11. // 基 于 SparkConf 实例 化 SparkContext 
2 val sc = new SparkContext( conf) 

13. /具体 的 业务 逻辑 

14. 

5; } 
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除了 set( ) 方 法 外 ，SparkConf 针对 常用 的 配置 项 也 专门 提供 了 对 应 的 方法 ， 如 可 以 用 
setAppName( ) 和 setMaster( ) 来 配置 spark. app. name 和 spark. master， 所 以 上 述 代 码 也 可 以 写 
成 下 面 这 种 形式 。 


object WordCount | © 























1 

多 def main( args: Array[ String | ) | 

3 // 实 例 化 SparkConf 

4. val conf = new SparkConf( ) 

5. // 设 置 程序 名 称 

6 conf. setAppName("My Spark App" ) 
7 // 设 置 master 

8 conf. setMaster( local[4|) 

9 // 设 置 port 

10. conf set( " spark. ui. port" ," 36000" ) 
11. // 基 于 SparkConf 实例 化 SparkContext 
2 val sc = new SparkContext( conf) 

13. /具体 的 业务 逻辑 

14. 

15. } 

MG 


通过 spark - submit 配置 Spark 











通过 SparkConf 配置 spark 是 通过 在 程序 中 人 硬 编码 来 配置 的 ， 而 在 大 多 数 情 况 下 ， 针 对 
有 具体 的 应 用 程序 动态 地 进行 配置 更 为 灵活 方便 。Spark 提供 了 一 种 机 制 ， 允 许 用 户 在 使 用 
spark - submit 提交 程序 时 动态 地 提供 配置 项 ， 这 些 配置 项 能 被 spark 识别 并 在 构建 SparkConf 
实例 时 使 用 。 所 以 ， 可 以 在 程序 中 构建 空 的 SparkConf 实例 ， 并 用 它 来 进一步 构建 SparkCon- 
text , 而 具体 的 配置 项 则 可 以 在 用 spark — submit 提交 程序 时 针对 具体 的 集群 状态 动态 地 提 
供 。spark - submit 有 一 个 通用 的 flag: - conf， 通 过 它 可 以 对 任意 配置 项 赋值 ; 除 此 之 外 ， 
spak - submit 针对 常见 的 配置 参数 专门 提供 了 一 系列 内 置 的 flag 以 方便 使 用 。 
因此 ， 可 以 将 程序 代码 写成 下 列 形式 。 























1 object WordCount | 

2 def main( args: Array[ String | ) | 

3 // 实 例 化 空 的 SparkConf 

4. val conf = new SparkConf( ) 

5 // 基 于 SparkConf 实例 化 SparkContext 
6 val sc = new SparkContext( conf) 

% 

8 

9 


// 具 体 的 业务 逻辑 


| 
10. | 





然后 用 下 面 的 spark - submit 在 提交 程序 时 指定 参数 。 
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$ bin/spark - submit \ 

一 class com. example. MyApp \ 
一 master local[4] \ 

一 name " My Spark App" \ 

一 conf spark. ui. port =36000 \ 


1. 
2 
3 
4. 
Sa 
6. 


myApp. jar 


通过 配置 文件 配置 Spark 


spark — submit 也 支持 从 文件 中 读 取 配置 项 ， 这 对 于 设置 多 用 户 多 应 用 共享 的 环境 参数 
而 言 非常 有 有用。 默认 情况 下 ，spark - sbumit 会 尝试 在 Spark 根 日 录 的 conf 目录 下 查找 文件 
spark - defaults. conf， 该 文件 包含 空格 间隔 的 一 系列 key/value 键 值 对 。 当 然 也 可 以 用 - prop- 
erties -file 来 指定 具体 的 文件 路 径 ， 如 下 所 示 。 








1 $ bin/spark - submit \ 

2 一 class com. example. MyApp \ 

3 一 properties — file my — config. conf \ 
4 myApp. jar 

5. 折 # Contents of my - config. conf 拓 
6 spark. master local[ 4] 

了 spark. app. name " My Spark App" 

8 spark. ui. port 36000 


Spark 配置 机 制 总 结 





通过 以 上 分 析 ， 总 结 起 来 可 知 ，Spark 中 的 配置 项 有 者 干 个 地 方 可 以 配置 : 通过 文件 
(如 conf/spark - defaults. confh) 配置 通过 spark - submit 在 提交 程序 时 配置 ;通过 程序 代 
码 中 的 SparkConf 硬 编码 配置 。 有 些 情况 下 ， 同 样 的 配置 项 可 能 在 这 些 不 同 的 地 方 都 做 了 配 
置 ， 比 如 在 程序 中 通过 setAppName( ) 设 置 了 程序 名 ， 在 spark - submit 中 也 通过 -name 设置 
了 程序 名 。 那 么 究 竞 哪个 生效 呢 ? 这 就 涉及 优先 级 问题 。 

程序 人 硬 编码 中 通过 SparkConf 对 象 的 set( ) 方 法 指定 的 配置 项 优先 级 最 高 ， 其 次 是 spark — 
submit 提交 程序 时 通过 -flag 设置 的 配置 项 ， 然 后 是 参数 文件 中 的 配置 项 ， 最 后 是 默认 值 。 

要 想 知 道 程序 运行 时 配置 项 的 具体 值 ， 可 以 查看 程序 运行 的 webUI。 

在 spark - Shell 交互 式 编程 终端 下 ， 可 以 通过 sc. getConf toDebugString 来 查看 SparkConf 
的 值 ， 通 过 sc. hadoopConfiguration. iterator( ) 来 获得 Hadoop 的 配置 信息 。 

需要 说 明 的 一 点 是 ， 几 乎 所 有 的 配置 都 可 以 通过 SparkConf 来 配 实现 , 但 是 有 一 个 例外 : 
SPARK_LOCAL_DIRS， 该 参数 用 来 配置 Spark 的 本 地 存储 目录 (这 些 目录 在 Shuffle 时 需要 
用 到 ) 。 由 于 在 具体 的 物理 结 点 上 该 目录 可 能 不 同 ， 需 要 在 conf/spark - env. sh 中 通过 export 
SPARK_LOCAL_DIRS 到 一 系列 逗号 分 隔 的 目录 来 配置 该 配置 项 。 











Section | 


在 进行 性 能 优化 前 ， 首 先 需 要 了 解 程序 的 运 
进行 优化 。Spark 记录 了 应 用 程序 详细 的 进度 信息 、 性 能 指标 等 细节 信息 ， 
0 用 户 使 用 : QDWebUI;@Driver 和 Executor 的 日 志 。 可 以 通过 查 


日 志文 件 来 了 解 应 用 程序 执行 


搞 人 。 


性 能 诊断 


性 能 优化 








Vs 


和 运 位 











了 的 细节 ， 进 行 诊断 进而 找到 性 能 


SE 


状况 ， 做 出 性 能 诊断 后 ， 才能 有 针对 性 地 


这 些 信息 通过 两 
看 分 析 WebUI 


bE 瓶 贷 ， 最 后 做 出 有 针对 性 的 


需要 说 明 的 是 ，WebUI 由 若干 个 Tab 页 面 构成 ， 在 不 同 的 Spark 版 本 中 Tab 页 面 可 能 





) 





有 不 同 ， 这 里 基于 当前 最 新 的 Spark1. 6. 1 版 本 进行 说 明 。 
9.2.1 WebUI 的 8080 端口 
集群 WebUI 的 8080 主页 面 如 下 所 示 ， 在 这 里 可 以 查看 集群 的 状态 信息 ， 如 Worker 是 否 











以 及 最 近 结 束 的 应 用 程序 的 信 


正常 ，Worker 的 Core 和 Memory 大小， 
息 等 ， 如 图 9-1 所 示 。 


正在 运行 的 应 用 程序 ， 





Spark Master at spark:/.,, x We I rowsim 


€ S$|@master 


Spa 和 161 Spark Master at spark://master:7077 





Workers 


Worker ld Address 


worker-20160504024659-192.168.198.144-4679 
worker-20160504024705-192.168.198.142-37640 
Running Applications 


Application ID Memory per Node 


Completed Applications 

Application ID 

app-20160504161057-0001 Spark word count demo 
)p-20160504150645-000 Spark shell 





DY Problem loading page x 


192.168.198.144:46799 
192.168.198.142:37640 


Memory per Node 
2.0 GB 
2.0GB 


+ 


State 
ALIVE 
ALIVE 


Memory 
2.0 GB (0.0 B Used) 
2.0 GB (0.0 B Used) 


Submitted Time 


Submitted Time 
2016/05/04 16:10:57 root 


State 
FINISHED 


2016/05/04 15:06:45 root FINISHED 








9-1 WebUI 


在 WebUI 的 8080 于 由 加 中 市 下 在 加 4 云 行 的 
i i 2 所 示 的 页 面 ， 
的 相关 信息 /DO 9 








否 获得 了 Executor， 


这 是 Application 的 主页 面 ， 
Executor 所 在 的 Worker 结 


的 8080 主页 面 








或 最 近 运 行 结 束 的 应 用 程序 的 Application id ， 
在 这 里 可 以 看 到 该 Application 


点 ， 以 及 Executor 的 Core、 


Memory 和 State 息 ， 当 然 也 包括 Executor 的 日 志 信 息 ， 如 图 9-2 所 示 。 





在 WebUI 的 8080 主页 面 单 击 正在 运行 的 


入 如 图 9-3 所 示 的 页 面 ， 这 是 Application 的 详细 情况 页 面 ， 包 括 若 干 个 Tab ， 即 Jobs、 
如 图 9-3 所 示 。 


es、 Storage 、Environment 和 Executors, 





或 最 近 运 行 结 束 的 应 用 程序 的 Name， 可 以 进 


Sta- 









内 核 机 制 解析 及 性 能 调 优 





(人 )@master808o/app/zappld=app-z0160504161057-0001 


ve][Q search 





| 太白 加 时 全 名 习 





User: root 


State: FINISHED 


ExecutorlD 


ExecutorlD 
1 
0 


Application Detail UI 


Spaik: ‘61 Application: Spark word count demo 


ID: app-20160504161057-0001 
Name: Spark word count demo 


Cores: Unlimited (4 granted) 


Executor Memory: 20 GB 
Submit Date: Wed May 04 16:10:57 CST 2016 


Executor Summary 


Worker 


Removed Executors 


Worker 
worker-20160504024705-192.168.198.142-37640 
worker-20160504024659-192.168.198.144-46799 


Cores Memory 


Logs 


Logs 
stdout stderr 


stdout stderr 












































到 9-2 ”Application 的 主页 面 
Spark word count dem... x Wenlli: Er x 二 Problemloadingpage x 中 
€ 本 master 二 ; 评 自 台 4 会 中 三 
? 
Spark Jobs (?) 
Total Uptime: 1.3 min 
Scheduling Mode: FIFO 
Completed Jobs: 2 
» Event Timeline 
Completed Jobs (2) 
yob ld Description Submitted Duration Stages; Succeeded/Total Tasks (for all stages): Succeeded/Total 
1 collect at wordCount.scala:25 2016/05/04 16:11:51 0.9s 2/2 (1 skipped) 41/4 (2 skipped) 
0 Fr | 2016/05/04 16:11:00 51s 22 44 








图 9-3 Application 的 详细 情况 页 面 


WebUI 的 18080 端口 








) 


结束 的 应 用 程序 的 信息 /EN » 
山口 来 访问 History Server， 从 而 











而 对 于 那些 较 早 前 运行 名 0 则 需要 通过 18080 端 
查看 集群 运行 的 应 用 程序 的 历史 信息 。 
在 History Server 的 主页 面 中 ， 可 以 查看 集群 





集群 WebUI 的 8080 端 





能 够 看 到 正在 运行 的 和 最 近 运 行 














的 状态 信息 ， 如 worker 是 否 正 常 ，worker 的 
以 及 最 近 结 束 的 应 用 程序 的 信息 等 ， 如 图 9-4 








core 和 memory 大 小 > 
所 示 。 


Spark word count dem 


正在 运行 的 应 用 程序 ， 


History server 


" arowsinehprs x | OnlineBlackListFilter-s 





€ 国 master 家 自已 人 会 驯 | 三 


Spaik: 1s, History Server 


Event log directory: hdfs://master:9000/historyserverforspark 
Showing 1-7 of7 





1 

AppID App Name Started Completed Duration Spark User Last Updated 
app-20160504163549-0002 Spark shell 2016/05/04 16:35:47 2016/05/04 16:36:56 12 min root 2016/05/04 16:36:56 

Spark word count demo 2016/05/04 16:10:36 2016/05/04 16:11:52 1.3 min root 2016/05/04 16:11:52 

Spark shell 2016/05/04 15:06:42 2016/05/04 16:09:37 1.0h root 2016/05/04 16:09:37 

OnlineBlackListFiter 2016/05/02 22:23:30 2016/05/02 22:26:41 3.2 min root 2016/05/02 22:26:41 

OnlineBlackListFiter 2016/05/02 00:22:33 2016/05/02 00:29:14 6.7 min root 2016/05/02 00:29:15 

OniineBlackListFiter 2016/05/02 00:18:50 2016/05/02 00:20:39 1.8 min root 2016/05/02 00:20:59 

OnlineBlackListFiter 2016/05/02 00:05:45 2016/05/02 00:08:52 3.1 min root 2016/05/02 00:08:52 























图 9-4 History Server 的 主页 面 
在 se Server 的 主页 面 单 击 某 个 应 用 程序 的 app id， 即 可 进入 Application 的 评 细 1 情况 


页 面 ， 该 页 面包 括 若 干 个 tab， 即 Jobs 、Stages、 Environment 和 Executors ， 该 页 面 与 
过 8080 端口 进入 的 Application 的 详细 情况 页 面 一 样 ， 如 图 9-5 所 示 。 





Storage 、 





通过 





gazaa 


叮 9 


性 能 优化 


章 





ee eT EE Spark word count dem... x Wome el 


x | OnlineBlackListFilter-s... x | 中 





€ Bmaster 会 自已 六 会 包 三 
spaik: Jobs | Sta Stora nvironment 。 Executor Spark word count demo application 
? 

Spark Jobs (?) 

Total Uptime: 1.3 min 

Scheduling Mode: FIFO 

Completed Jobs: 2 

» Event Timeline 

Completed Jobs (2) 

yobld Description Submitted Duration Stages: Succeeded/Total Tasks (for all stages): Succeeded/Total 

1 collect at wordCountscala:2 2016/05/04 16:11:51 0.9s 2/2 (1 skipped) 4/4 (2 skipped) 

0 2016/05/04 16:11:00 51s 22 44 











图 9-5 History Server 的 Application 详细 





情况 页 面 











WebUI 的 4040 端口 


行 过 


程序 执行 过 程 中 也 可 以 通过 4040 端口 
干 个 tab， 即 Jobs、 


查看 Application 的 详细 情况 页 面 ， 该 页 面包 括 大 
这 跟 通 过 8080 端口 或 18080 





Stages 、Storage 、 





Environment 和 Executors ， 





端口 进入 的 Application 的 详细 情况 页 面 一 样 ， 如 图 9-6 所 示 。 


Spark word count dem 


x ，OnlineBlackListFilter -Ss... x | Browsing HDFS 





By OnlineBlackListFilter-s... x Wa 











€, |@master 全 自已 上 会 所 
Spaiks 衣 Jobs | Stages Storage Environment Executors Streamin¢ OnlineBlackListFilter application U 
Spark Jobs (?) 
Total Uptime: 2.7 min 
g Mode: FIFO 
lete 
» Event Timeline 
Active Jobs (1) 
Jobld Deseription Submitted Duration Stages: Succeeded/Total Tasks (for all stages): Succeeded/Total 
1 Streaming job running receiver 0 2016/05/04 16:39:41 52s o1 ol 
lineBlackListFilte 
Completed Jobs (4) 
yobld Description Submitted Duration Stages: Succeeded/Total Tasks (for all stages): Succeeded/Total 
4 meer a wy out opera 2016/05/04 16:40:00 0.1s 1/1 (2 skipped) 3/3 (9 skipped) 
3 En Jo from [ 2016/05/04 16:40:00 02s 1/1 (2 skipped) 41/4 (9 skipped) 
2 Streaming job from [outpui ope ):00 2016/05/04 16:40:00 0.3s 3/3 10/10 
prir lineBl Filter 
0 art at OnlineBlackListFilter 2016/05/04 16:38:23 1.3min 2/2 70m70 








不 管 通过 
Stages、 





ss 


过 哪 种 方式 ， 


Storage 、 


图 9-6 4040 端 


Environment 和 Executors, 








山口 的 Application 详细 情况 页 面 














入 的 Application 的 详细 情况 页 面 都 包含 若干 个 Tab 页 面 ， 即 
这 些 Tab 页 面向 用 户 展示 了 程序 的 运 


行 细 


， 接 下 来 仔细 讲解 各 个 Tab 页 面 。 





WebUI 的 Jobs 页 面 


Job 页 面 展 示 了 job 的 详细 执行 信息 ， 如 图 9-7 所 示 。 
单 击 某 个 Job 可 以 进入 该 Job 的 细节 页 面 ， 细 节 页 面 展示 了 该 Job 的 Stages 和 Tasks 的 细 


如 图 9-8 所 示 。 


二 












内 核 机 制 解析 及 性 能 调 优 


Spark word count dem. x | Spark word count dem, x | Browsing HDFS bb OnlineBlackListFilter -5... x 





4 写本 master © | [& search 妆 自 加 合生 
Spark Jobs (?) 


Total Uptime: 27 min 
Scheduling Mode: FIFO 
Active Jobs:1 
Completed Jobs: 4 
~ Event Timeline 

Enable zooming 
Executors 

Added Executor 0 added 


Removed Executor 1 added 


Jobs 
Succeeded 
国 Faied 


Running start at OnlineBlackListFilter.scala:66 (Job 0) 


Streaming iob running receiver 0 (Job 1) 





























20 30 40 50 0 10 20 30 40 50 0 10 20 30 
4 May 16:38 4 May 16:39 4 May 16:40 
Active Jobs (1) 
Jobld Description Submitted Duration Stages: Succeeded/Total Tasks (for all stages): Succeeded/Total 
1 Streaming job running receiver 0 2016/05/04 16:39:41 52s 01 01 
start at OnlineBlackListFilter.scala:66 
Completed Jobs (4) 
Jobld Description Submitted Duration Stages: Succeeded/Total Tasks (for all stages): Succeeded/Total 
4 Streaming job from [output operation 0, batch time 16:40:00] 2016/05/04 16:40:00 0.1s 1/1 (2 skipped) 3/3 (9 skipped) 
print at OnlineBlackListFiter.scala:61 
3 Streaming job from [output operation 0, batch time 16:40:00] 2016/05/04 16:40:00 0.2s 1/1 (2 skipped) 4/4 (9 skipped) 
print at OnlineBlackListFilter.scala:6 
2 Streaming job from [output operation 0, batch time 16:40:00] 2016/05/04 16:40:00 03s 33 10/10 
print at OnlineBlackL istFilter.scala:6 
> 
图 9-7 Jobs 主页 面 
Spark word count dem..，*x 是 于 
€ master [a 全 自己 如 角 多 三 
Spa 和 人 Jobs 0 torage vironrr tor Spark word count demo a 
Details for Job 0 
上 status: SUCCEEDED 
Completed Stages: 2 
Stage0 Siage1 
iexiFlle reauceByKey 
map 
中 mwap 
soheykey 
map 
Completed Stages (2) 
Stage ld Description Submitted Duration 。 Tasks: Succeeded/Total Input Output Shuffle Read Shuffle Write 
1 2016/05/04 16:11:51 0.2s 22 37KB 
0 2016/05/04 16:1100 50s 22 49KB 3.7KB 











图 9-8 Jobs 的 细节 页 面 


败 























WebUI 的 Stages 页 面 








Stage 页 面 展 示 了 Stage 的 详细 执行 言 息 ， 在 每 个 Stage 内 部 ， 该 页 面 也 提供 了 若干 met- 
rics 来 帮助 用 户 更 好 地 理解 作业 物理 执行 的 细节 。 常 用 该 页 面 来 评估 Job 的 performance。 
通常 首先 会 查看 构成 Job 的 各 个 Stage， 查 看 是 否 有 运行 非常 缓慢 的 Stage， 或 在 该 Job 
的 若干 次 运行 时 ， 响 应 时 间 变 化 很 大 的 Stage。 确 定好 了 问题 Stage 后 ,会 进一步 查看 该 
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Stage 的 详细 情况 ， 以 定位 性 能 瓶颈 。 

分 布 式 系统 常见 的 一 个 性 能 问题 是 “倾斜 ”"， 即 若干 个 Task 相对 于 其 他 大 多 数 Task 来 
说 消耗 了 相当 长 的 时 间 ， 可 以 通过 查看 Task 的 Metrics 来 判断 是 否 有 倾斜 。Task 运行 了 多 
久 ， 是 否 有 些 Task 相对 其 他 Task 来 说 需要 多 得 多 的 运行 时 间 ， 如 果 是 的 话 ， 就 需要 进一步 
分 析 这 些 Task 执行 慢 的 原因 ; 是 否 有 些 Task 相对 其 他 Task 来 说 ， 读 或 写 了 多 得 多 的 数据 ; 
是 否 某 些 结 点 上 的 Task 都 运行 得 特别 慢 ， 等 等 。 这 些 都 是 在 进行 性 能 诊断 时 首先 要 关注 的 
问题 。 还 要 关注 Task 在 读 ， 计 算 和 写 的 各 个 阶段 消耗 了 多 少时 间 ， 如 果 Task 读 写 数据 消耗 
的 时 间 不 多 而 整体 消耗 时 间 较 多 ， 则 可 能 是 因为 应 用 程序 代码 的 问题 ， 就 需要 考虑 代码 的 优 
化 ; 也 可 能 有 些 Task 几乎 所 有 的 时 间 都 消耗 在 从 外 部 存储 系统 读 取 数据 上 了 ， 这 时 瓶颈 在 
输入 的 读 取 上 ， 单 纯 优 化 Spark 可 能 就 没什么 很 大 帮助 了 。 

Stages 页 面 的 主页 如 图 9-9 所 示 。 


















































€ Bmas 


ter 
ai 181 Pp g Spark word count demo 


Stages for All Jobs 


4 


Completed Stages (4) 


Stageld Description Submitted Duration Tasks: Succeeded/Total Input Output Shutfle Read Shuffle Write 
4 2016/05/04 16:11:51 08s 22 3.1KB 
2016/05/04 16:1151 77 ms 22 37 KB 3.1KB 
1 2016/05/04 16:11:51 02s 22 37KB 
0 2016/05/04 16:1100 50s 22 4.9 KB 37KB 








图 9-9 Stages 主页 面 
单 击 某 个 Stage， 即 可 以 进入 到 Stage 的 细节 页 面 ， 如 图 9-10 所 示 。 





Spark word count dem... x WEIS 


€)@master. 4 全 自己 此 会 四 己 


Spa ,,, Jobs | Stages Storage Environment Executors Spark word count demo application U 


Details for Stage 4 (Attempt 0) 


Total Time Across All Tasks: 63 ms 
Locality Level Summary: Node local: 2 
Shuffle Read: 3.1 KB / 260 

»DA 人 izatior 

» Show Addi 

» Event Timelir 


Summary Metrics for 2 Completed Tasks 


Metric Min 25th percentile Median 75th percentile Max 
Duration 31 ms 31 ms 32ms 32 ms 32 ms 
Scheduler Delay 19 ms 19 ms 0.1s 0.1s 0.1s 
Task Deserialization Time 0.6s 06s 0.7s 07s 07s 
GC Time 0 ms 0 ms 0ms 0ms 0ms 
Result Serialization Time 1 ms 1ms 1 ms 1ms 1 ms 
Getting Result Time 0 ms 0ms 0ms 0ms 0ms 
Peak Execution Memory 6.9 KB 6.9 KB 18.1 KB 18.1 KB 18.1 KB 
Shuffle Read Blocked Time 0ms 0ms 0ms 0ms 0ms 
Shuffle Read Size / Records 911.0B172 911.0B/72 2.2 KB/188 2.2 KB/ 188 2.2 KB/188 
Shuffle Remote Reads 0.0B 0.0B 0.0B 00B 00B 


Aggregated Metrics by Executor 
Executor ID a Address Task Time Total Tasks Failed Tasks Succeeded Tasks Shuffle Read Size / Records 
1 worker2:52401 2s 2 0 2 3.1 KB/260 


图 9-10 ”Stage 的 细节 页 面 











WebUI 的 Storage 页 面 


Storage 页 面包 含 了 持久 化 的 RDD 的 相关 信息 。 









内 核 机 制 解析 及 性 能 调 优 





大 家 知道 ， 当 我 们 在 应 用 程序 中 显 式 地 对 一 个 RDD 调用 了 persist( ) 或 cache( ) 后 ， 在 后 

















续 通 过 某 个 Job 计算 了 该 RDD 后 ,该 RDD 就 会 被 持久 化 起 来 。 通 过 对 持久 化 的 源 代码 的 分 
析 ， 可 以 知道 ， 当 对 多 个 RDD 持久 化 时 ， 如 果 存 储 空间 不 够 ， 较 早 的 RDD 可 能 会 被 清除 ， 
以 便 为 较 新 的 RDD 腾 出 空间 。 

了 解 程序 执行 时 持久 化 的 细节 ， 是 在 进行 性 能 诊断 时 必须 关注 的 。 到 哪里 了 解 这 些 细节 
呢 ? 图 9-11 所 示 的 页 1 面向 用 户 展 示 了 缓存 的 RDD 的 缓存 后 RDD 的 大 小 ， 缓 存 的 级 
别 〈 是 缓存 到 磁盘 ， 缓 存 到 内 存 ， 还 是 都 有 ， 等 等 ) 。 这 些 细节 ， 可 以 知道 重要 的 数据 
是 否 被 正确 地 缓存 了 

Storage 页 面 如 图 9-11 所 示 。 


让 

















Spark word count dem,. x 


€ @master 人 六 自 加 时 全 人 三 
Spa 和 bs Stages Storage Environment Executors Spark word count demo application L 
Storage 
| RDDs 
RDD Name Storage Level Cached Partitions Fraction Cached Size in Memory Size in ExternalBlockStore Size on Disk 
hdfs://n 1:9000) README.r Memory Deserialized 1x Replicated 2 100% 10.2 KB 0.0B 0.0B 





图 9-11 Storage 页 面 








WebUI 的 Environment 页 面 ) 








通过 9. 1 节 中 对 Spark 配置 机 制 的 分 析 ， 可 以 知道 有 多 种 配置 方式 ， 其 中 有 些 是 系统 管 
理 员 做 的 配置 ， 有 些 是 提交 程序 时 动态 指定 的 配置 ， 还 有 些 是 应 用 程序 中 硬 编码 指定 的 配 
置 ， 而 且 这 些 配 置 有 优先 级 ， 有 的 配置 会 覆盖 其 他 地 方 的 配置 。 

程序 运行 时 真正 生效 的 配置 是 什么 呢 ? Environment 页 面 就 展示 了 应 用 程序 执行 的 过 程 
中 所 使 用 的 实际 的 具体 配置 信息 ，Environment 页 面 如 图 9-12 一 图 9-14 所 示 ， 之 所 以 分 成 
3 个 图 ， 是 因为 该 页 Ss \ 很 多 ， 分 为 不 同 的 方面 。 








和 D problem loadingpage x 中 
€ 国 master 7G 六 自 回 合作 三 


Spaik® 1,, Jobs Stages Storage ，Environment Executors Spark word count demo application UI 





Environment 


Runtime Information 


Name Value 
Java Home /ust/liblavalidk1.8.0_60/ire 
Java Version 1.8.0_60 (Oracle Corporation) 
Scala Version version 2.10.5 


Spark Properties 


Name Value 





spark.driver.host 192.168.198.136 
spark.history fs.logDirectory hdfs://master-9000/historyserverforspark 
spark.eventLog.enabled true 
spark driver.port 44509 
spark jars fileyrootworkspace/SparkCoreApsjar 
spark app.name Spark word count demo 
spark.scheduler.mode FIFO 
spark.driver.memory 2g 
spark.executorid driver 
sparksubmitdeployMode client 
spark master sparlclmaster7077 

29 

hds://master-9000 /historyserverforspark 
spark.extemalBlockStore .folderName spark-83425834-a97c-4006-a6f1-127782750dd4 
spark.app.id app-20160504161057-0001 











图 9-12 Environment 的 Runtime Information 和 Spark Properties 页 面 
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如 图 9-12 展示 了 Runtime Information 和 Spark Properties， 图 9-13 展示 了 System Proper- 
ties， 图 9-14 展示 了 Classpath Entries。 








Spark word count dem.. BEDLA El Ea 


所  @master vC 内 


System Properties 
Name Value 
javaiotmpdir 二 
line.separator 


path.separator 


sun.management.compiler HotSpot 64-Bit Tiered Compilers 
SPARK_SUBMIT true 

sun.cpu.endian little 

java.specification.version 1.8 

java.vm.specification.name Java Virtual Machine Specification 
java.vendor Oracle Corporation 
java.vm.specification.version 1.8 

User.home /root 

file.encoding.pkg sun.io 


sun.nio.ch.bugLevel 





sun.arch.data.model 64 

sun.boot.library.path lusr/lib/java/jidk1.8.0_60/ire/lib/lamd64 

user.dir /root/workspace 

java.library.path lusr/javalpackages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib 
sun.cpu.isalist 

sun.desktop gnome 

os.arch amd64 

java.vm.version 25.60-b23 

java.endorsed.dirs lusr/lib/ijavaljdk1.8.0_60/ire/lib/endorsed 
java.runtime.version 1.8.0_60-b27 

java.vm.info mixed mode 

java.ext.dirs lusrilib/javalidk1.8.0_60/ire/lib/ext:/usr/java/packages/lib/ext 
java.runtime.name Java(TM) SE Runtime Environment 














图 9-13 Environment 的 System Properties 页 国 














Spark word count dem... Namenode information 
€ 国 master 六 自 回 号 全 9 

Sun-os-paicriever unknown 

java vm.specification.vendor Oracle Corporation 

user.country Us 

sunjnu.encoding UTF-8 

userlanguage en 

java vendor url httpWjava oracle com/ 

java awt printerjob sun_print PSPrinterJob 

java_awt graphicsenv sun_awt X11GraphicsEnvironment 
awttoolkit sun_awt X11.XToolkit 

os name Linux 

java vm.vendor Oracle Corporation 

java vendor urlbug httpJ/bugreport.sun.comybugreport 
user.name root 

java.vm.name Java HotSpot(TM) 64-Bit Server VM 
sunjavacommand org.apache.spark.deploy.SparkSubmit --master spark://master:7077 --class com.dt.spark.core.wordCount /root/workspace 

SparkCoreApsjar 

java home usr/lib/java/idk1.8.0_60/ire 
javaversion 1.8.0 60 

sun.io.unicode.encoding UnicodeLitte 
Classpath Entries 

Resource Source 

ust/local/spark/spark-1.6.1-bin-hadoop2.6/lib/spark-assembly-1.6.1-hadoop2.6.0.jar System Classpath 

ust/local/spark/spark-1.6.1-bin-hadoop2.6/lib/datanucleus-api-jdo-3.2.6.jar System Classpath 

usr/local/spark/spark-1.6.1-bin-hadoop2.6/lib/datanucleus-rdbms-3.2.9 jar System Classpath 

usr/localhadoop/hadoop-2.6.0/etc/hadoop! System Classpath 
http:/192.168.198.136:53004/jars/SparkCoreAps.jar Added By User 

usr/local/spark/spark-1.6.1-bin-hadoop2.6/conf/ System Classpath 

usr/local/spark/spark-1.6.1-bin-hadoop2.6/lib/datanucleus-core-3.2.10.jar System Classpath 


























图 9-14 Environment 的 Classpath Entries 页 国 









内 核 机 制 解析 及 性 能 调 优 


需要 指出 的 是 ， 该 页 面 也 列举 了 应 用 程序 执行 时 实际 使 用 的 jars 和 fles， 这 对 于 诊断 程 
序 运行 时 的 依赖 缺失 等 错误 很 有 帮助 。 


WebUI 的 Executors 页 面 





Executors 页 面 展示 了 应 用 程序 申请 到 的 所 有 的 Executors 相关 信息 ， 如 图 9-15 所 示 。 


€ maskter 


Spai ee Jobs Stages Storage Environment Executors 


Executors (3) 


Memory: 10.2 KB Used (3.7 GB Total) 
Disk: 0.0 B Used 


Executor RDD Storage Disk Active Failed Complete Total Task Shuffle Shuffle 


ID Address Blocks Memory Used Tasks Tasks Tasks Tasks Time Input Read Write Logs 
0 worker1:41090 0 0.0B/1247.3 0.0B 0 0 0 0 0 ms 0.0B 0.0B 0.0B stdout 
der 
1 worker2:52401 这 10.2 KB/ 0.0B 0 0 8 8 1.7 m 4.9 0.0B 6.8 KB stdout 
1247.3 MB KB stder 
driver 192.168.198.136:49047 0 0.0B/1247.3 0.0B 0 0 0 0 0 ms 0.0B 0.0B 0.0B 


MB 











9-15 ”Executors 页 面 


性 能 诊断 时 ， 需 要 首先 查看 该 页 面 以 确定 应 用 程序 是 和 否 申请 到 了 足够 多 的 Executors 
资源 。 由 于 集群 环境 的 复杂 性 ， 很 多 时 候 ， 集 群 中 的 某 些 结 点 上 不 恰当 的 配置 会 导致 
在 这 些 结 点 上 申请 不 到 Executors 来 执行 应 用 程序 ， 则 应 用 程序 所 能 申请 到 的 总 的 Exec- 














utors 个 数 就 不 一 定 满足 需要 ， 人 性 能 相应 地 就 不 理想 ， 此 时 就 要 调整 这 些 相 应 结 点 的 配 
置信 息 。 


举例 来 说 ， 如 果 该 页 面 显示 的 某 些 Executors 上 执行 的 任务 中 有 很 多 执行 的 非常 慢 甚 至 
错误 的 任务 的 话 ， 就 应 该 认真 关注 该 Executor 及 其 所 在 Worker 结 点 的 配置 ， 并 进行 相应 
的 调整 ， 有 必要 时 甚至 可 以 移 除 这 些 结 点 ， 以 避免 在 这 些 结 点 上 分 配 Executors 来 执行 
任务 。 


2 Driver 和 Executor 的 日 志 | 


除了 WebUI， 另 一 个 可 以 获取 到 程序 执行 时 具体 信息 的 地 方 是 Driver 和 Executor 的 日 
志 。 这 些 日 志 包 含 了 程序 执行 时 很 多 的 细节 ， 如 代码 抛 出 的 警告 和 异常 等 ， 这 些 信 息 也 有 助 
于 性 能 诊断 。 

日 志文 件 的 地 址 跟 程 序 运行 的 模式 有 关 。 在 Standalone 模式 下 ， 这 些 日 志 在 Master 的 
WebUI 上 可 以 直接 显示 出 来 ， 其 物理 位 置 默 认 情 况 下 存储 在 Worker 结 点 Spark 根 目 录 下 的 
work 目录 下 ; 在 Mesos 模式 下 ， 可 以 通过 Mesos masterUI 来 访问 这 些 日 志 ， 其 物理 位 置 存储 
在 Mesos 的 Slave 的 Work 目录 下 ; 在 YARN 模式 下 ， 最 简单 的 收集 日 志 的 方式 是 使 用 YARN 
提供 的 日 志 收 集 工 具 (运行 命令 yarn logs - applicationId < app ID > ) ， 不 过 该 工具 只 有 在 程 
序 运行 结束 后 才能 收集 到 这 些 日 志 信息 ， 在 程序 运行 期 间 ， 需 要 从 ResourceManager UI 进入 
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具体 的 结 点 ， 然 后 进入 具体 的 container 来 查看 日 志 。 

需要 说 明 的 是 ， 也 可 以 配置 Spark 的 日 志 系 统 log4j 来 更 改 日 志 输 出 的 级 别 。Spark 提供 
了 一 个 log4j 的 配置 文件 模板 conf/log4j. properties. template ， 可 以 复制 该 文件 到 log4j. properties ， 加 
然后 修改 复制 后 的 文件 ， 比 如 将 logging level 从 默认 情况 下 的 INFO 修改 为 WARN 或 ERROR (>) 
来 产生 更 少 的 日 志 输 出 信息 。 配 置 完成 后 ， 可 以 在 spark - submit 提交 程序 时 通过 - files 
log4j. properties 来 指定 程序 运行 时 使 用 的 日 志 配 置 文件 。 


性 能 优化 


了 解 了 Spark 的 配置 机 制 ， 也 知道 了 如 何 查看 程序 运行 时 的 细节 信息 来 进行 性 能 诊断 
后 ， 接 下 来 就 能 有 针对 性 地 对 性 能 瓶颈 做 出 优化 了 。 

需要 说 明 的 是 ， 如 果 集 群 的 资源 是 弹性 的 ， 简 单 地 通过 增 大 CPU 内 核 数量 、 增 大 内 存 
或 网 络 带宽 等 方式 ， 当 然 也 能 提升 程序 的 性 能 。 这 里 说 的 性 能 优化 是 指 在 硬件 资源 固定 ， 也 
就 是 集群 的 内 存 、CPU 、 磁 盘 和 网 络 带 宽 等 资源 固定 的 情况 下 ， 通 过 修改 参数 ， 调 整 配 置 ， 
甚至 修改 程序 业务 逻辑 代码 ， 来 优化 性 能 。 

当然 ， 性 能 的 优化 是 一 个 动态 的 过 程 ， 不 可 能 一 劳 永 逸 ， 这 里 讲解 的 方法 也 并 没有 涵盖 
所 有 的 内 容 ， 只 是 讲解 了 常见 的 Spark 性 能 优化 的 方法 ， 读 者 在 使 用 过 程 中 需要 反复 调试 、 
不 断 摸索 ， 才 能 找到 最 适合 自己 的 集群 和 程序 的 方案 。 


程序 编写 准则 有 


从 根本 上 讲 ，Spark 程序 的 性 能 取决 于 用 户 编 写 的 程序 。 所 以 在 讲解 具体 的 优化 方法 之 
前 ， 首 先 简单 描述 一 下 Spark 程序 编写 需要 注意 的 地 方 。 在 开发 过 程 中 ， 要 时 刻 牢记 这 些 原 
则 ， 根 据 具体 的 业务 逻辑 ， 将 这 些 原则 结合 起 来 ， 灵 活 地 运用 它们 。 

1. 准则 一 ， 从 同一 个 数据 源 尽 量 只 创建 一 个 RDD， 后 续 不 同 的 业务 逻辑 可 以 复 用 该 
RDD， 而 不 是 基于 该 数据 源 重新 创建 一 个 新 的 RDD 

这 是 因为 ， 从 数据 源 创 建 RDD 常常 涉及 数据 的 读 取 ， 而 数据 的 读 取 速度 一 般 都 比 数据 
计算 的 速度 慢 ， 所 以 要 减少 从 外 部 数据 源 加 载 数据 的 次 数 ， 尽 量 复 用 RDD 而 不 是 重新 创建 
新 的 RDD ， 这 点 在 程序 业务 逻辑 复杂 宛 长 的 情况 下 常常 被 忽视 ， 一 个 错误 的 示例 代码 如 下 
所 示 : 












































1 object WordCount | 

2 def main( args: Array[ String | ) | 

3 // 实 例 化 空 的 SparkConf 

4. val conf = new SparkConf( ) 

5 // 基 于 SparkConf 实例 化 SparkContext 
6 


val sc =new SparkContext( conf) 









内 核 机 制 解析 及 性 能 调 优 








元 // 具 体 的 业务 逻辑 :需要 对 名 为 README. md 的 HDFS 文件 进行 一 次 map 操作 ,再 进行 
一 次 reduce 操作 。 也 就 是 说 ,需要 对 一 份 数据 执行 两 次 算 子 操作 
8. // 错误 的 做 法 :对 同一 份 数据 源 执行 多 次 算 子 操作 时 ,创建 了 两 个 RDD ,然后 分 别 对 每 


个 RDD 都 执行 了 一 个 算 子 操作 。 这 种 情况 下 ,Spark 需要 两 次 从 HDFS 上 加 载 RE- 
ADME. md 文件 的 内 容 , 并 创建 两 个 单独 的 RDD。 第 二 次 加 载 HDFS 文件 及 创建 
RDD 的 动作 显然 是 不 必要 的 


























9. val rddl = sc. textFile( "hdfs://master:9000/data/ README. md " ) 

10. rddl. map( ...) 

i val rdd2 = sc. textFile( " hdfs://master:9000/data/ README. md " ) 

| 多 rdd2. reduce( ...) 

13. // 进 一 步 的 具体 业务 逻辑 

14. A 

15. // 正确 的 用 法 ;对 同一 份 数据 源 执行 多 次 算 子 操作 时 ,只 创建 一 个 RDD ,然后 复 用 该 





RDD 执行 多 次 算 子 操 作 。 这 种 情况 下 ,Spark 仅仅 需要 从 HDFS 上 加 载 一 次 RE- 
ADME. md 文件 的 内 容 





16. val rddl = sc. textFile( "hdfs://master:9000/data/ README. md " ) 
17. rddl. map( ...) 

18. rddl. reduce( ...) 

To 

20. | 


当然 ， 由 于 Spark 程序 执行 时 的 延迟 执行 和 基于 Lineage 最 大 化 的 pipeline 的 特性 ， 由 于 
rddl 被 执行 了 两 次 算 子 操作 (一 次 map， 一 次 reduce) ， 在 执行 reduce 操作 时 ， 还 会 再 次 从 
源头 重新 计算 一 次 rddl 的 数据 ， 即 再 次 重新 从 HDFS 加 载 外 部 数据 源 的 数据 。 所 以 ， 要 想 
彻底 解决 重复 读 取 外 部 数据 源 的 问题 ， 还 需 结合 “准则 二 ， 如 果 需 要 对 某 个 RDD 进行 多 次 
不 同 的 transformation 和 action 操作 以 应 用 于 不 同 的 业务 分 析 需 求 ， 可 以 考虑 对 该 RDD 进行 
持久 化 操作 ， 以 避免 action 操作 触发 作业 时 多 次 重复 计算 该 RDD”， 才 能 保证 一 个 RDD 被 多 
次 使 用 时 只 被 计算 一 次 。 

2. 准则 二 :如果 需 要 对 某 个 RDD 进行 多 次 不 同 的 Transformation 和 Action 操作 以 应 
用 于 不 同 的 业务 分 析 需 求 ， 可 以 考虑 对 该 RDD 进行 持久 化 操作 ， 以 避免 Action 操作 触发 作 
业 时 多 次 重复 计算 该 RDD 

需要 考虑 该 准则 是 因为 Spark 程序 执行 的 特性 ， 即 延迟 执行 和 基于 Lineage 最 大 化 的 
pipeline。 简 单 来 说 ，Spark 中 由 于 对 某 个 RDD 的 Action 操作 触发 了 作业 时 ， 会 基于 Lineage 
从 后 往 前 推 ， 找 到 该 RDD 源头 的 RDD， 然 后 从 前 往 后 计算 出 结果 。 很 明显 ， 如 果 对 某 个 
RDD 执行 了 多 次 Transformation 和 Action 操作 ， 每 次 Action 操作 触发 了 作业 时 都 会 重新 从 源 
头 RDD 处 计算 一 遍 来 获得 该 RDD， 然 后 再 对 这 个 RDD 执行 相应 的 操作 。 这 种 方式 的 性 能 显 
然 是 很 差 的 。 

所 以 需要 对 多 次 使 用 的 RDD 进行 持久 化 。 持 久 化 之 后 ，Spark 就 会 根据 持久 化 策略 ， 将 
RDD 中 的 数据 保存 到 内 存 或 者 磁盘 中 。 以 后 每 次 对 该 RDD 进行 算 子 操作 时 ， 都 会 直接 从 内 
存 或 磁盘 中 提取 持久 化 的 RDD 数据 ， 然 后 执行 算 子 ， 而 不 会 从 源头 处 重新 计算 一 遍 这 个 
RDD， 青 执行 算 子 操作 。 
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3. 准则 三 : 从 数据 源 读 取 数 据 获 得 RDD 后 ， 要 尽早 进行 flter 过 滤 掉 不 需要 的 数据 

Spark 是 居于 内 存 的 迭代 计算 模型 ,将 不 必要 的 数据 尽早 过 滤 掉 (filter), 减少 内 存 的 
占用 ， 从 而 提高 程序 的 执行 效率 。 

需要 说 明 的 是 ， 如 果 filter 后 会 获得 大 量 小 文件 ， 可 能 需要 通过 repartition 或 coalesce 减 O) 
小 并 行 度 。 

4. 准则 四 : 尽量 避免 使 用 需要 Shuffle 的 算 子 ， 且 在 必须 Shuffle 时 尽量 减少 shuffle 的 
数据 量 

如 果 有 可 能 ， 要 尽量 避免 使 用 Shuffle 类 算 子 。 因 为 Spark 作业 运行 过 程 中 ， 最 消耗 性 能 
的 地 方 就 是 Shuffle 过程 。Shuffle 过 程 就 是 数据 洗 牌 ， 简 单 来 说 ， 就 是 将 分 布 在 集群 中 多 个 
结 点 上 的 包含 同一 个 key 的 数据 ， 拉 取 到 同一 个 结 点 上 ， 然 后 进行 聚合 或 join 等 操作 。redu- 
ceByKey 、join 等 算 子 都 会 触发 Shuffle 操作 。 

Shuffle 过 程 中 ， 各 个 结 点 上 的 相同 key 都 会 先 写 入 本 地 磁盘 文件 中 ， 然 后 其 他 结 点 需要 
通过 网 络 传输 拉 取 各 个 结 点 上 的 磁盘 文件 中 的 含有 相同 key 的 记录 。 在 将 这 些 含有 相同 key 
的 数据 都 拉 取 到 同一 个 结 点 进行 聚合 操作 时 ， 还 有 可 能 会 因为 一 个 结 点 上 处 理 的 key 过 多 ， 
导致 内 存 不 够 存放 ， 进 而 溢 写 到 磁盘 文件 中 。 因 此 在 Shuffle 过 程 中 ， 可 能 会 发 生 大 量 的 磁 
盘 文 件 读 写 操作 ， 以 及 数据 的 网 络 传输 操作 ， 而 这 无 疑 也 会 降低 程序 的 执行 速度 。 

因此 在 开发 过 程 中 ， 应 当 尽 可 能 避免 使 用 reduceByKey 、join 、distinct 和 repartition 等 会 
进行 Shuffle 的 算 子 ， 而 尽量 使 用 Map 类 的 非 Shuffle 算 子 。 这 样 的 话 ， 没 有 Shuffle 操作 或 者 
仅 有 较 少 Shuffle 操作 ， 程序 的 执行 就 可 以 大 大 减少 性 能 开销 。 

如 果 因 为 业务 需要 ， 一 定 要 使 用 Shuffle 操作 且 无 法 用 Map 类 的 算 子 来 蔡 代 时 ， 就 要 尽 
量 减 少 Shuffle 的 数据 量 ， 可 以 通过 使 用 map - side 预 聚合 的 算 子 来 减少 Shuffle 的 数据 量 。 

所 谓 的 map - side 预 聚 合 ， 指 的 是 在 每 个 结 点 本 地 map 时 ， 对 含有 相同 的 key 记录 进行 
了 聚合 操作 ， 这 点 类 似 于 MapReduce 中 的 本 地 combiner。map - side 预 聚合 之 后 ， 每 个 结 点 
本 地 就 只 会 有 一 条 含有 相同 的 key 的 记录 (因为 多 条 含有 相同 的 key 的 记录 都 被 聚合 起 来 ) 。 

其 他 结 点 在 拉 取 所 有 结 点 上 的 含有 相同 的 key 的 记录 时 ， 就 会 大 大 减少 需要 拉 取 的 数据 数 
量 ， 从 而 也 就 减少 了 磁盘 IO 和 网 络 传输 开销 。 

这 里 以 ReduceByKey/AggregateByKey 与 groupByKey 的 对 比 来 说 明 map - side 预 聚合 的 重 
要 性 。ReduceByKey/aggregateByKey 算 子 会 使 用 用 户 自 定义 的 函数 对 每 个 结 点 本 地 的 含有 相 
同 key 的 记录 进行 预 聚 合 。 而 groupByKey 算 子 是 不 会 进行 预 聚合 的 ， 全 部 的 数据 都 会 在 集 
群 的 各 个 结 点 之 间 分 发 和 传输 ， 性 能 相对 来 说 肯定 比较 差 。 

GroupByKey 与 ReduceByKey 的 原理 图 如 图 9-16 和 图 9-17 所 示 。 

从 图 中 我 们 可 以 看 出 ，groupByKey 不 会 进行 map 端的 预 聚 合 ， 而 是 将 所 有 map 端的 数 
据 shuffle 到 reduce 端 ， 然 后 在 reduce 端 进行 聚合 操作 。 

从 图 中 我 们 可 以 看 出 ，reduceByKey 会 首先 在 map 端 进行 预 聚 合 操作 ， 然 后 将 聚合 后 的 
数据 shuffle 到 reduce 端 ， 由 于 map 端的 预 聚合 操作 会 减 小 数据 量 ， 所 以 需要 在 网 络 中 传输 
的 数据 量 就 减 小 了 ， 效率 也 就 比 groupByKey 更 高 。 

使 用 ReduceByKey 替代 groupByKey 的 实例 代码 如 下 。 
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GroupByKey 





LE 图 








ReduceByKey 


(21) _ (a, 1) 2 ,1) _ (a,3) 
(b, 1) (b, 1) 








图 9-17 ReduceByKey 原理 图 





val words = Array( " Spark" , "Scala" ," Hadoop" , "Java" ," Mapreduce" ," RDD" ) 

val wordPairsRDD = sparkcontext. parallelize ( words ). map( word => (word ,1 )) 

// 使 用 groupByKey 的 实现 

val WordCountByGroup = wordPairsRDD. groupByKey( ). map(t => (t. _1,t. _2. sum) ). collect( ) 
// 使 用 reduceByKey 的 实现 

val WordCountByReduce = wordPairsRDD. reduceByKey( _ +_). collect( ) 


CN A le 


S. 准则 五 : 熟悉 各 个 算 子 的 背后 机 制 ， 选 择 使 用 高 性 能 的 算 子 

Spark 的 一 大 特性 就 是 提高 了 丰富 的 算 子 以 满足 不 同 的 业务 需要 。 一 个 良好 的 程序 员 需 要 熟 
知 这 些 算 子 的 背后 机 制 ， 能 够 选择 使 用 高 性 能 的 算 子 满足 业务 需求 。 这 里 列举 几 个 常见 的 实例 。 

相对 来 说 ， 可 以 使 用 reduceByKey/ aggregateByKey 替代 groupByKey。 

相对 来 说 ， 可 以 使 用 mapPartitions 替代 普通 Map， 因 为 mapPartitions 类 的 算 子 ， 一 次 函 
数 调用 会 处 理 一 个 Partition 所 有 的 数据 ， 而 不 是 一 次 函数 调用 处 理 一 条 ， 所 有 性 能 相对 来 说 
会 高 一 些 。 但 是 有 时 候 ， 使 用 mapPartitions 会 出 现 OOM (内 存 溢出 ) 的 问题 。 为 单 次 函 
数 调 用 就 要 处 理 一 个 Partition 所 有 的 数据 ， 如 果 内 存 不 够 ,垃圾 回收 时 是 无 法 回收 太 多 对 象 
的 ， 很 可 能 出 现 OOM 异常 。 所 以 使 用 这 类 操作 时 要 慎重 。 

相对 来 说 ， 可 以 使 用 foreachPartitions 替代 foreach， 原 理 类 似 于 “使 用 mapPartitions 替代 
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Map”， 也 是 一 次 函数 调用 处 理 一 个 Partition 的 所 有 数据 ， 而 不 是 一 次 函数 调用 处 理 一 条 数据 。 

这 个 实例 一 个 常见 的 经 典 应 用 场景 是 在 写 记录 到 数据 库 时 ， 如 果 是 普通 的 foreach 算 子 ， 每 次 
函数 调用 都 需要 创建 一 个 数据 库 连 接 ， 然 后 写 一 条 数据 ， 此 时 势必 会 频繁 地 创建 和 销毁 数据 库 
连接 ， 性 能 非常 低下 ; 但 是 如 果 用 foreachPartitions 算 子 一 次 性 处 理 一 个 Partition 的 数据 ， 那 么 对 O) 
于 每 个 Partition 只 要 创建 一 个 数据 库 连 接 ， 然 后 执行 批量 插入 操作 ， 此 时 性 能 肯定 是 比较 高 的 。 

相对 来 说 ， 可 以 使 用 repartitionAndSortWithinPartitions 替代 Repartition 与 Sort 类 操作 。 事 
实 上 ，repartitionAndSortWithinPartitions 是 Spark 官网 推荐 的 一 个 算 子 ， 如 果 在 Repartition 重 
分 区 之 后 还 要 进行 排序 ， 官 方 建议 直接 使 用 repartitionAndSortWithinPartitions 算 子 ， 因 为 该 算 
子 可 以 一 边 进行 重 分 区 的 Shuffle 操作 ， 一 边 进行 排序 。Shuffle 与 Sort 两 个 操作 同时 进行 ， 
比 先 Shuffle 再 Sort 来 说 ， 性 能 肯定 是 比较 高 的 。 

对 一 个 RDD 执行 filter 算 子 后 ， 如 果 可 能 过 滤 掉 RDD 中 较 多 的 数据 (比如 30% 以 上 的 
数据 ) ， 就 建议 使 用 coalesce 算 子 ， 手 动 减少 RDD 的 Partition 数量 ,将 RDD 中 的 数据 压缩 到 
更 少 的 Partition 中 去 ， 以 减少 并 行 度 ， 避 免 过 多 开辟 Task 的 开销 。 因 为 Filter 之 后 ，RDD 的 
每 个 Partition 中 都 会 有 很 多 数据 被 过 滤 掉 ， 此 时 如 果 照 常 进行 后 续 的 计算 ， 每 个 Task 处 理 
的 Partition 中 的 数据 量 并 不 是 很 多 ， 而 且 此 时 开辟 的 Task 越 多 ， 可 能 速度 反而 越 慢 ， 因 为 
Task 的 开辟 和 销毁 也 是 有 开销 的 。 因 此 可 以 用 coalesce 来 减少 partition 数量 ,将 RDD 中 的 数 
据 压 缩 到 更 少 的 Partition ， 只 需 使 用 更 少 的 Task 即 可 处 理 完 所 有 的 Partition。 

6. 准则 六 : 对 大 变量 考虑 使 用 广播 机 制 

有 时 在 开发 过 程 中 ， 会 遇 到 需要 在 算 子 函数 中 使 用 外 部 大 变量 的 场景 (比如 100M 的 大 
集合 ) ， 那 么 此 时 就 可 以 考虑 使 用 Spark 的 广播 (Broadcast) 功能 来 提升 性 能 。 

在 算 子 函数 中 使 用 到 外 部 变量 时 ， 默 认 情 况 下 ，Spatk 会 将 该 变量 复制 多 个 副本 ， 通 过 
网 络 传输 到 Task 中 ， 此 时 每 个 Task 都 有 一 个 变量 副本 。 如 果 变 量 本 里 比较 大 的 话 (比如 
100 MB， 甚 至 1 GB) ， 那 么 大 量 的 变量 副本 在 网 络 中 传输 的 性 能 开销 ， 以 及 在 各 个 结 点 的 
Executor 中 占用 过 多 内 存 导 致 的 频繁 GC ， 都 会 极 大 地 影响 性 能 。 

因此 对 于 上 述 情况 ， 如 果 使 用 的 外 部 变量 比较 大 ， 建 议 使 用 Spark 的 广播 功能 ， 对 该 变 
量 进行 广播 。 广播 后 的 变量 会 保证 每 个 Executor 的 内 存 中 只 驻 留 一 份 变量 副本 ， 而 Executor 中 
的 Task 执行 时 共享 该 Executor 中 的 那 份 变量 副本 。 这 样 的 话 ， 可 以 大 大 减少 变量 副本 的 数量 ， 
从 而 减少 网 络 传输 的 性 能 开销 ， 并 减少 对 Executor 内 存 的 占用 开销 ， 降 低 GC 的 频率 。 

7. 准则 七 : 尽 可 能 使 用 Kryo 优化 序列 化 性 能 

Spark 默认 的 序列 化 器 是 org. apache. spark. serializer. JavaSerializer, 但 同时 也 支持 使 用 
Kryo 序列 化 器 org. apache. spark. serializer. KryoSerializer。 由 于 默认 的 序列 化 器 的 性 能 和 空间 
表现 都 比较 差 ， 而 Kryo 序列 化 器 更 快 ， 压 缩 率 也 更 高 ， 所 以 我 们 应 该 优先 使 用 Kryo 序列 化 
器 而 不 是 默认 的 序列 化 器 。 

8. 准则 八 : 使 用 优化 的 数据 结构 

Spark 应 用 程序 同 普通 程序 一 样 需要 考虑 数据 结构 问题 ， 由 于 Spark 是 优先 基于 内 存 的 
迭代 计算 模型 ， 尤 其 需要 考虑 使 用 内 存 友好 的 数据 结构 。 在 可 能 及 合适 的 情况 下 ， 应 该 使 用 
占用 内 存 较 少 的 数据 结构 。 

由 于 数据 结构 的 知识 是 通用 的 ， 不 单单 只 在 Spark 程序 里 需要 考虑 ， 这 里 仪 简单 描述 一 








































































































































































内 核 机 制 解析 及 性 能 调 优 


下 常见 的 数据 结构 ， 更 详细 的 情况 请 读者 自行 分 析 。 

Java 语言 的 特性 导致 有 些 数 据 结构 会 占用 额外 的 空间 ， 在 Java 中 有 以 下 3 种 类 型 的 数 
据 结构 比较 耗费 内 存 。 

1) Java 的 对 象 : 每 个 Java 对 象 都 有 对 象 头 ， 对 象 头 占用 额外 的 16 个 字 节 (包含 指向 
对 象 的 指针 等 元 数据 信息 ) ， 如 果 对 象 中 只 有 一 个 int 类 型 的 变量 ， 则 此 时 会 占据 20 个 字 
节 ， 也 就 是 说 对 象 的 元 数据 占用 了 大 部 分 的 空间 ， 所 以 在 封装 数据 时 尽量 不 要 使 用 对 象 ， 可 
以 使 用 JSON 格式 来 封装 数据 。 需 要 注意 ，Java 中 基本 的 数据 类 型 会 自动 进行 封 箱 操 作 ， 例 
如 ，int 会 自动 变 成 Integer， 这 也 会 额外 增加 对 象 头 的 空间 占用 。 

2) Java 的 字符 串 : 每 个 字符 串 内 部 都 有 一 个 字符 数组 及 长 度 等 额外 信息 ， 在 实际 占用 
内 存 方 面 要 额外 使 用 40 个 字 节 (每 个 字符 串 内 部 都 使 用 字符 数组 来 保存 字符 序列 ) 。 由 于 
字符 串 中 的 每 个 字符 占用 2 个 字 节 (UTF - 16 编码 ) ， 所 以 如 果 字 符 串 内 部 有 5 个 字符 的 
话 ， 实 际 上 会 占用 50 个 字 节 。 

3) Java 中 的 集合 类 型 (如 HashMap 、List 等 ) : 集合 的 内 部 一 般 使 用 链表 来 实现 ， 具 体 
的 每 个 数据 则 使 用 Entry 等 ， 这 些 也 非常 消耗 内 存 。 

所 以 Spark 官方 建议 用 户 ， 在 Spark 编码 实现 中 ， 特 别 是 对 于 算 子 函数 中 的 代码 ， 尽 量 
使 用 字符 串 奉 代 对 象 ， 使 用 原始 类 型 (如 Int 和 Long) 替代 字符 串 ， 使 用 原生 数组 替代 集合 
类 型 ， 这 样 会 尽 可 能 地 减少 内 存 占 用 ， 从 而 降低 GC 频率 ， 提升 性 能 。 例 如 ，List < Integer > 
list = new ArrayList < Integer > 需要 考虑 改 为 使 用 int[ ]arrary = new int[ ] 。 

如 果 内 存 少 于 32 GB， 可 以 在 spark - env. sh 中 设置 JVM 参数 - XX: + UseCompressed0O- 
ops， 以 便 使 用 4 字 节 指针 而 不 是 8 字 节 指针 。 与 此 同时 ， 在 Java 7 或 者 更 高 版 本 中 ， 设 置 
JVM 参数 - XX: + UseCompressedStrings， 以 便 采 用 8 位 来 编码 每 一 个 ASCII 字符 。 


并 行 度 是 


并 行 度 指 的 就 是 RDD 的 分 区 数 ， 由 于 一 个 分 区 对 应 一 个 Task， 并 行 度 也 是 一 个 Stage 
中 的 Task 数 ， 这 些 Task 被 并 行 处 理 。 通 过 前 面 的 章节 可 以 知道 ，RDD 是 以 Partition 即 分 区 
的 形式 散落 在 集群 上 的 ， 每 个 分 区 都 包含 一 部 分 待 处 理 的 数据 ，Spark 程序 运行 时 ， 会 为 每 
个 待 处 理 的 分 区 创建 一 个 Task， 且 默认 情况 下 每 个 task 占用 一 个 CPU Core 来 处 理 。 

Spark 有 一 套 自己 自动 推导 出 默认 的 分 区 数 的 机 制 。 当 在 程序 中 通过 操作 算 子 如 textFile 
等 读 取 外 部 数据 源 以 获得 Input RDD 时 ，Spark 会 自动 地 根据 外 部 数据 源 的 大 小 推导 出 一 个 
合适 的 默认 分 区 数 ， 如 HDFS 文件 的 每 个 Block 就 对 应 一 个 分 区 ; 在 对 RDD 进行 Map 类 不 
涉及 Shuffle 的 操作 时 ， 由 于 分 区 数 具 有 遗传 性 ， 新 产生 的 RDD 的 分 区 数 由 parent RDD 中 最 
大 的 分 区 数 决定 ; 在 对 RDD 进行 Reduce 类 涉及 Shuffle 操作 的 算 子 时 (如 groupByKey 、re- 
duceByKey 等 各 种 Reduce 操作 算 子 ) ， 由 于 分 区 数 具 有 遗传 性 ， 新 产生 的 RDD 的 分 区 数 也 
由 Parent RDD 中 最 大 的 分 区 数 决定 。 如 果 是 在 Spark - Shell 交互 式 命令 终端 下 ， 可 以 通过 方 
法 rdd. partitions. size 来 获得 某 个 RDD 的 分 区 数 ， 而 在 Spark 1. 6. 0 以 后 的 版 本 中 ， 也 可 以 通 
过 rdd. getNumPartitions( ) 来 获得 某 个 RDD 的 分 区 数 。 

并 行 度 对 性 能 的 影响 有 两 方面 ， 当 并 行 度 不 够 大 时 会 存在 资源 的 闲置 与 浪费 ， 比 如 一 个 
应 用 程序 分 配 到 了 1000 个 Core， 但 是 一 个 stage 里 只 有 30 个 Task ， 此 时 就 可 以 提高 并 行 度 
以 提升 硬件 利用 率 ; 而 当 并 行 度 太 大 时 ，Task 常常 几 微 秒 就 执行 完毕 ， 或 Task 读 写 的 数据 
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量 很 小 ， 这 种 情况 下 ，Task 频繁 地 开辟 与 销毁 的 不 必要 的 开销 则 太 大 ， 就 需要 调 小 并 行 度 。 

由 于 Spark 自动 推导 出 来 的 默认 分 区 数 很 多 时 候 并 不 理想 ， 必 须 人 为 地 加 以 控制 来 改变 
并 行 度 。Spark 提供 了 4 种 改变 并 行 度 的 方式 。 

第 一 种 ， 在 使 用 读 取 外 部 数据 源 的 textFile 类 算 子 时 ， 可 以 通过 可 选 的 参数 minPartitions O) 
来 显示 指定 最 小 的 分 区 数 。 

第 二 种 ， 针 对 已 经 存在 的 RDD ， 可 以 通过 方法 repartition( ) 或 coalesce( ) 来 改变 并 行 度 。 
repartition( ) 和 coalesce( ) 的 区 别 在 于 ， 前 者 会 产生 Shuffle， 而 后 者 默认 不 会 产生 Shuffle。 事 
实 上 ， 当 有 大 量 小 任务 (任务 处 理 的 数据 量 小 且 耗 时 短 ) 时 ， 比 如 某 个 RDD 在 Filter 操作 
后 ， 由 于 过 滤 掉 了 大 量 数 据 ， 每 个 分 区 都 只 剩 下 了 很 少量 的 数据 ， 这 时 和 常用 coalesce( ) 来 合 
并 分 区 ， 调 小 并 行 度 ， 减 少 不 必 要 的 任务 开辟 与 销毁 的 消耗 ; 而 当 任务 耗 时 长 且 处 理 的 数据 
量 大 时 ， 如 果 计 算 只 发 生 在 部 分 Executor 上 ， 人 常用 repartition( ) 来 重新 分 区 ， 提 高 并 行 度 ， 
开辟 更 多 的 并 行 计算 的 任务 来 完成 计算 。 

第 三 种 ， 在 对 RDD 进行 Reduce 类 涉及 Shuffle 操作 的 算 子 时 ， 这 些 算 子 大 都 可 以 接受 
一 个 显 式 指定 的 参数 来 确定 新 产生 的 RDD 的 分 区 数 ， 我 们 可 以 显 式 地 指定 这 类 参数 来 改变 
Shuffle 后 新 产生 的 RDD 的 分 区 数 ， 而 不 是 采用 系统 推导 出 的 默认 的 分 区 数 。 

第 四 种 ， 也 可 以 配置 参数 spark. default parallelism 来 设置 默认 的 并 行 度 。 该 参数 其 实 指 
定 的 就 是 在 对 RDD 进行 Reduce 类 涉及 Shuffle 操作 的 算 子 时 ， 如 果 没 有 对 这 些 算 子 显示 指 
定 参 数 来 确定 新 产生 的 RDD 的 分 区 数 时 ， 这 类 Reduce 类 涉及 Shuffle 操作 的 算 子 产生 的 新 
的 RDD 的 Paritition 数量 。 该 参数 也 指定 了 Parallelize 等 没有 Parent RDDs 类 操作 的 算 子 所 产 
生 的 新 的 RDD 的 分 区 数 。 

一 个 最 佳 实践 是 ， 将 并 行 度 设置 为 集群 的 总 的 CPU Cores 个 数 的 2 ~ 3 倍 ， 比 如 Execu- 
tor 的 总 CPU Core 数量 为 400 个 ， 那 么 设置 1000 个 Task 是 可 以 的 ， 此 时 可 以 充分 利用 Spark 
集群 的 资源 ; 每 个 分 区 的 大 小 在 128 MB 左右 。 

需要 说 明 的 是 ， 通 过 以 上 方式 确定 了 任务 的 并 行 度 ， 就 确定 了 理论 上 能 够 并 行 执行 的 任 
务 的 数量 ， 而 实际 执行 时 真正 并 发 执行 的 任务 数量 还 要 受到 应 用 分 配 到 的 实际 资源 数量 的 限 
制 ， 要 想 改变 应 用 程序 获得 的 资源 数目 ， 这 就 涉及 资源 参数 的 调 优 。 


资源 参数 调 优 


所 谓 Spark 资源 参数 调 优 ， 其 实 主要 就 是 对 Spark 程序 运行 过 程 中 各 个 使 用 资源 的 地 方 ， 
通过 调节 各 种 参数 来 优化 资源 使 用 的 效率 ， 从 而 提升 Spark 作业 的 执行 性 能 。 需 要 考虑 的 资 
源 主 要 是 分 配给 各 个 Executors 的 Core 的 个 数 和 内 存 ， 分 配给 程序 的 Executors 总 个 数 ， 以 及 
分 配 的 本 地 磁盘 数 等 。 

Spark 应 用 程序 的 每 个 Executors 都 有 固定 的 一 样 的 Core 和 内 存 。 

每 个 Executors 的 内 存 ， 在 各 种 模式 下 ， 都 可 以 通过 Spark - Submit 的 - executor - memory 
参数 ， 或 spark — defaults. conf 配置 文件 的 spark. executor. memory 参数 来 指定 。Executors 内 存 
的 大 小 很 多 时 候 直 接 决 定 了 Spark 作业 的 性 能 ， 而 且 跟 常见 的 JVM 00M 异常 也 有 直接 关联 。 
但 该 值 不 是 越 大 越 好 ， 因 为 太 大 的 堆 空间 会 引起 GC 垃圾 回收 的 延迟 ， 该 堆 大 小 的 最 大 值 建 
议 不 超过 64 GB。 

每 个 Executor 的 Core 个 数 和 申请 的 Executors 的 总 个 数 ， 在 YARN 模式 下 ， 可 以 通过 
spark - submit 的 - executor - cores 参数 和 - num - executors 参数 来 分 别 指定 ， 也 可 以 通过 
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spark - defaults. conf 配置 文件 中 的 spark. executor. cores 参数 和 spark. executor. instances 参数 来 
分 别 指定 ; 在 Standalone 和 Mesos 模式 下 ， 由 于 Spark 程序 会 尽 可 能 多 地 占用 所 有 可 用 的 
Core 和 创建 尽 可 能 多 的 Executors ， 所 以 可 以 通过 参数 spark. cores. max 来 指定 程序 申请 的 Ex- 
ecutors 的 Core 总 个 数 。 因 为 每 个 CPU Core 同一 时 间 只 能 执行 一 个 Task 线程 ， 所 以 每 个 Ex- 
ecutor 进程 的 CPU Core 数量 越 多 ， 越 能 够 快速 地 执行 完 分 配给 自己 的 所 有 的 Task 线程 。 但 
是 还 需要 考虑 到 文件 系统 的 IO 吞吐 量 ， 一 个 最 佳 实践 是 ， 建 议 为 每 个 Executor 设置 5 个 或 
5 个 以 下 的 Core。 

Spark 使 用 Executor 的 本 地 磁盘 来 存储 Shuffle 时 的 临时 数据 和 Spill 到 磁盘 上 的 被 缓存 的 
RDD 分 区 ， 配 置 使 用 多 个 本 地 磁盘 可 以 提升 Spark 的 性 能 。 在 YARN 模式 下 ，YARN 有 自己 
的 配置 本 地 磁盘 的 机 制 ; 在 Standalone 模式 下 ， 可 以 在 conf/spark - env. sh 中 配置 环境 变量 
SPARK_LOCAL_DIRS; 在 Mesos 模式 下 ， 可 以 配置 选项 spark. local. dir. 这 3 种 配置 模式 都 可 
以 配置 多 个 文件 目录 ， 多 个 文件 目录 之 间 需 要 用 逗号 隔 开 。 

由 于 每 一 台 Host 上 面 可 以 并 行 N 个 Worker， 每 一 个 Worker 下 面 可 以 并 行 M 个 Execu- 
tor， 每 个 Executor 可 以 占用 一 个 或 多 个 Core， 而 Task 会 被 分 配 到 Executor 上 去 执行 且 默 认 
情况 下 一 个 Task 占用 一 个 Core， 所 以 可 以 通过 观察 CPU 的 使 用 率 变化 来 了 解 计 算 资 源 的 使 
用 情况 。 若 CPU 利用 率 很 低 且 程序 运行 缓慢 ， 就 可 以 尝试 减少 每 个 Executor 占用 的 cpu 
cores 的 数量 ， 增 加 并 行 的 Executors 数量 ， 同 时 配合 增加 数据 分 片 ， 整 体 上 增加 CPU 的 利用 
率 ， 加 快 数据 处 理 速 度 ; 若 Job 很 容易 发 生 内 存 溢出 ， 就 可 以 尝试 增 大 分 片 数量 ， 从 而 减少 
每 个 数据 分 片 的 大 小 ， 同 时 减少 并 行 的 Exeeutors 的 数量 ， 这 样 相 同 的 内 存 资源 分 配给 数量 
更 少 的 Executors ， 相 当 于 增加 了 每 个 Task 的 内 存 分 配 ， 这 样 运行 速 度 可 能 慢 了 些 ， 但 是 总 
比 OOM 强 ; 看 数据 量 特别 少 ， 有 大 量 的 小 文件 生成 ， 就 可 以 尝试 减少 数据 分 片 ， 没 必要 创 
建 那么 多 的 Task， 其 实 这 种 情况 如 果 只 是 最 原始 的 输入 文件 比较 小 ， 一 般 都 能 被 注意 到 ， 
但 是 如 果 是 在 运算 过 程 中 ， 比 如 应 用 某 个 reduceByKey 或 者 Filter 后 ， 数 据 大 量 减少 ， 这 种 
低 效 情况 就 很 少 被 留意 到 ， 要 特别 注意 。 

当 为 Executors 分 配 好 内 存 后 ， 也 可 以 通过 参数 进一步 控制 内 存 如 何 使 用 ， 如 内 存 的 多 
少 可 以 用 来 计算 ， 内 存 的 多 少 可 以 用 来 做 持久 化 操作 等 ， 涉 及 的 参数 在 Spark 的 不 同 版 本 中 
有 所 不 同 ，Spark 1.6.0 之 前 所 使 用 的 内 存 管理 模式 由 类 StaticMemoryManager 实现 ， 而 Spark 
1. 6.0 后 所 使 用 的 内 存 管理 模式 由 类 UnifiedMemoryManager 实现 ， 进 一 步 的 调 优 细节 请 参考 
9. 3.5 内 存 调 优 。 

需要 注意 的 是 ， 资 源 参数 的 调 优 不 是 一 劳 永 逸 的 ， 需 要 根据 实际 作业 执行 情况 动态 调 
整 。 资 源 参 数 的 调 优 没有 一 个 固定 的 值 ， 随 着 参数 和 配置 的 变化 ， 性 能 的 瓶颈 是 变化 的 ， 这 
就 需要 根据 自己 的 实际 情况 (包括 Spark 作业 中 的 Shuffle 操作 的 数量 、RDD 持久 化 操作 的 
数量 ， 以 及 Spark WebUI 中 显示 的 作业 GC 情况 等 ) 来 动态 调整 配置 。 例 如 ， 在 每 台 机 硕 上 
部 署 的 Executors 数量 增加 时 ， 性 能 一 开始 是 增加 的 ， 同 时 也 观察 到 CPU 的 平均 使 用 率 在 增 
加 ; 但 是 随 着 单 台 机 器 上 的 Executors 数量 越 来 越 多 ， 性 能 却 开 始 下 降 了 ， 因 为 随 着 Execu- 
tors 数量 的 增加 ， 被 分 配 到 每 个 Executors 的 内 存 数 量 减 小 ,在 内 存 里 直接 进行 的 操作 越 来 越 
少 ，Spill 到 磁盘 上 的 数据 越 来 越 多 ， 自 然 性 能 就 变 差 了 。 


序列 化 与 压缩 习 
序列 化 有 时 是 shuffle 和 cache 的 瓶 希 ， 合 理 地 设置 序列 化 ， 不 但 能 提高 IO 性 能 (包括 
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网 络 LO 和 磁盘 IO) ， 还 能 减少 内 存 的 使 用 。 

Spark 默认 的 序列 化 器 是 org. apache. spark. serializer. JavaSerializer， 也 就 是 使 用 ObjectOut- 
putStream/ObjectInputStream API 来 进行 序列 化 和 反 序列 化 ， 但 是 这 个 默认 的 序列 化 器 的 性 能 和 空 
间 表 现 都 比较 差 。 Spark 同时 支持 使 用 Kryo 序列 化 器 org. apache. spark. serializer. KryoSerializer, 该 OO) 
序列 化 器 更 快 ， 压 缩 率 也 更 高 。 官 方 介绍 ，Kryo 序列 化 机 制 比 Java 序列 化 机 制 性 能 高 了 10 
倍 左右 ， 当 然 放 到 整个 Spark 程序 中 来 考量 ， 比 重 就 没有 那么 大 了 ， 但 是 以 WordCount 为 
例 ， 通 常 也 很 容易 达到 30% 以 上 的 性 能 提升 。 

Spark 之 所 以 没有 默认 使 用 Kryo 作为 序列 化 器 ， 是 因为 Kryo 并 不 支持 所 有 可 序列 化 的 
类 型 ， 且 要 求 最 好 注册 所 有 需要 进行 序列 化 的 自 定 义 类 型 ， 这 对 于 开发 者 而 言 略 显 麻 烦 。 推 
荐 在 所 有 网 络 0 密集 型 应 用 中 使 用 Kryo。 事 实 上 ，Spark 对 大 多 数 常用 的 scala 类 都 自动 包 
含 了 Kryo 序列 化 库 。 

在 Spark 中 ， 以 下 地 方 会 涉及 序列 化 : 在 算 子 的 函数 中 使 用 到 外 部 变量 时 ， 该 变量 会 被 
序列 化 后 通过 网 络 传输 到 task 中 ; 使 用 自 定义 的 类 型 作为 RDD 的 泛 型 类 型 时 ， 所 有 的 自 定 
义 类 型 对 象 都 会 进行 序列 化 ; 使 用 需 序 列 化 的 持久 化 策略 时 ( 比如 MEMORY_ONLY_SER ) ， 
Spark 会 将 RDD 中 的 每 个 Partition 都 序列 化 成 一 个 大 的 字 节 数组 ; Spark Task 需要 被 序列 化 
后 从 Driver 发 送 到 Executor 上 。 这 里 涉及 序列 化 的 4 个 地 方 ， 前 面 3 个 使 用 的 序列 化 器 都 可 
以 通过 设置 spark. serializer 来 使 用 Kryo 序列 化 ， 以 提高 性 能 ; 而 Spark Task 的 序列 化 是 通过 
spark. closure. serializer 来 配置 的 ,但 是 目前 它 只 支持 JavaSerializer。 

使 用 Kryo 序列 化 器 时 ， 只 要 设置 序列 化 器 为 Kryo， 再 注册 要 序列 化 的 自 定 义 类 型 即 可 
(比如 算 子 函数 中 使 用 到 的 外 部 变量 类 型 、 作 为 RDD 泛 型 类 型 的 自 定 义 类 型 等 ) 。 事 实 上 ， 
如 果 没 有 注册 自 定义 类 型 到 Kryo，Kryo 仍然 可 以 工作 ， 但 需要 对 每 个 该 类 型 的 对 象 都 存储 
完整 的 类 名 ， 当 有 百 万 条 其 至 更 多 的 序列 化 记录 时 ， 这 会 额外 占用 更 多 的 空间 ， 所 以 推荐 注 
册 自 定义 的 类 到 Kryo， 也 可 以 通过 设置 spark. kryo. registrationRequired 参数 为 true 来 强制 注 
册 ， 这 样 当 Kryo 遇 到 没有 注册 的 类 时 ， 会 抛 出 错误 。 

以 下 是 使 用 Kryo 序列 化 器 的 代码 示例 。 

















































































































// 创 建 SparkConf 对 象 。 

val conf = new SparkConf( ) 

// 设 置 序列 化 器 为 KryoSerializer。 

conf set(" spark. serializer" ," org. apache. spark. serializer. KryoSerializer" ) 
// 设 置 需 注册 自 定义 类 型 到 Kryo 

conf set( " spark. kryo. registrationRequired" , " true" ) 

// 注 册 要 序列 化 的 自 定义 类 型 

conf registerKryoClasses( Array( classOf[ MyClass | ,classOf[ MyOtherClass ] ) ) 


A ee 





在 程序 运行 过 程 中 ， 如 果 遇 到 了 错误 NotSerializableFxception ， 就 说 明 程序 代码 中 使 用 了 没 
有 实现 Java 的 Serializable 序列 化 接口 的 类 ， 需 要 修改 相应 的 类 ， 使 其 实现 该 接口 。 当 由 于 程 
序 中 使 用 了 很 多 类 而 不 好 判断 究竟 是 哪个 类 引起 该 问题 时 ， 可 以 通过 在 Spark - Submit 提交 程 
序 时 , 在 - driver - java - options 和 - executor - java - options 中 指定 - Dsun. io. serialization. 
extended DebugImfo = true 来 协助 判断 究竟 是 哪个 类 引起 的 该 问题 。 

压缩 和 解压 缩 会 消耗 CPU， 但 由 于 它 能 减少 数据 体积 ， 使 存储 和 传输 更 高 效 ， 所 以 在 
大 数据 分 布 式 计算 框架 下 很 有 用 。 Spark 中 压缩 相关 参数 为 ， Dspark. rdd. compress,， 该 参数 
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决定 了 RDD 数据 在 序列 化 之 后 是 否 进 一 步 进行 压缩 ， 然 后 再 储存 到 内 存 或 磁盘 上 ， 这 个 值 
默认 是 不 压缩 ， 但 是 如 果 在 磁盘 IO 的 确 成 为 问题 或 者 GC 问题 真 的 没有 其 他 更 好 的 解决 办 
法 时 ， 可 以 考虑 启用 RDD 压缩 ; (2)spark. broadcast. compress ， 该 参数 决定 了 是 否 对 Broadcast 
的 数据 进行 压缩 ， 默 认 值 为 True， 因 为 Broadeast 的 数据 需要 通过 网 络 发 送 ， 而 在 Executor 
端 又 需要 存储 在 本 地 BlockMananger 中 ， 所 以 通过 压缩 从 而 减 小 体积 来 减少 网 络 传输 开销 和 
内 存 占 用 通常 都 是 有 利于 提高 程序 整体 性 能 的 ; (spark. io. compression. codec, 该 参数 决 
定 了 用 来 压缩 内 部 数据 ， 比 如 RDD 分 区 、 广 播 变 量 和 Shuffle 输出 的 数据 等 ， 所 采用 的 压缩 
器 ， 有 3 种 选择 : lz4、lzf 和 snappy， 默 认 的 是 Snappy, 但 和 Snappy 相 比 较 ，lzf 的 压缩 率 比较 
高 ， 故 在 有 大 量 Shuffle 的 情况 下 ， 使 用 lzf 可 以 提高 Shuffle 性 能 ， 进 而 提高 程序 整体 效率 。 


内存 调 估 ) 


Spark 作为 分 布 式 计算 框架 ， 由 于 其 优先 使 用 内 存 ， 故 对 内 存 的 管理 对 性 能 有 重大 影 
响 ， 了 解 其 内 存 管理 机 制 及 对 内 存 的 使 用 情况 ， 也 大 大 有 助 于 程序 的 优化 。 

1. Spark 的 内 存 管理 机 制 

Spark 1.6.0 之 前 所 使 用 的 内 存 管 理 模式 由 类 StaticMemoryManager 实现 ( 见 图 9-18)， 
而 Spark 1. 6.0 之 后 所 使 用 的 内 存 管理 模式 由 类 UnifiedMemoryManager 实现 ( 见 图 9-19)， 
当然 也 可 以 通过 参数 spark. memory. useLegacyMode 来 配置 使 用 哪 种 内 存 管 理 模 式 。 





























存储 内 存 
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spark.storage.memoryFraction 




















展开 的 内 存 (存储 内 存 的 20%) 


spark.storage.unrollFraction 


Shuffle 内 存 〈 内 存 使 用 安全 系统 的 20%) 
spark.Shuffle.memoryFraction 


内 存 使 用 安全 系统 〔 堆 空间 的 90%) 


spark.storage.safetyFraction 




















Java 虚拟 机 堆 空间 (512MB) 


spark.executor.memory 








图 9-18 StaticMemoryManager 


Executor 中 对 内 存 的 使 用 涉及 以 下 几 点 。 

1) RDD 存储 。 当 对 RDD 调用 Persist 或 Cache 方法 时 ，RDD 的 Partition 会 被 存储 到 内 存 中 。 

2) Shuffle 操作 。Shuffle 时 ， 需 要 缓冲 区 来 存储 Shuffle 的 输出 和 聚合 的 中 间 结 

3) 用 户 代 码 。 用 户 编写 的 代码 所 能 使 用 的 内 存 空间 是 整个 堆 空 间 除 了 上 述 两 点 之 后 剩 
下 的 空间 。 

StaticMemoryManage 模式 下 ， 堆 空间 分 为 Storage 区 和 Shuffle 区 。Storage 区 所 能 使 用 的 
堆 空 间 的 比例 由 spark. storage. memoryFraction 指定 ， 默 认 值 为 0.6， 为 了 避免 内 存 溢出 的 风 
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图 9-19 UnifiedMemoryManager 


险 ， 使 用 参数 spark. storage. safetyFraction 来 指定 安全 区 比例 ， 该 参数 的 默认 值 为 0.9， 故 实 
际 可 用 的 Storage 区 为 堆 空间 的 0.54 (0.9 x0.6=0.54); shuffle 区 所 能 使 用 的 堆 空 间 的 比例 
由 spark. shuffle. memoryFraction 指定 ， 默 认 值 为 0.2， 为 了 避免 内 存 洲 出 的 风险 ,使 用 参数 
spark. shuffle. safetyFraction 来 指定 安全 区 比例 ， 该 参数 默认 值 为 0.8， 故 实际 可 用 的 shuffle 
区 为 堆 空间 的 0.16 (0.8 x0.2 =0.16)。 如 果 Spark 作业 中 有 较 多 的 RDD 持久 化 操作 ， 可 以 
将 spark. storage. memoryFraction 的 值 适 当 提 高 一 些 ， 保证 持久 化 的 数据 能 够 容纳 在 内 存 中 o 
避免 内 存 不 够 缓存 所 有 的 数据 ， 导 致 数据 只 能 写 和 磁盘 中 ， 降 低 了 性 能 。 但 是 如 果 Spark 作 
业 中 的 Shuffle 类 操作 比较 多 ， 而 持久 化 操作 比较 少 ， 那 么 可 以 将 spark. storage. memoryFrac- 
tion 的 值 适 当 降 低 一 些 ， 而 将 spark. shuffle. memoryFraction 的 值 适当 提高 一 些 ， 以 避免 shuffle 
过 程 中 数据 过 多 时 内 存 不 够 用 ， 必 须 淤 写 到 磁盘 上 而 降低 性 能 ;此 外 ， 如 果 发 现 作 业 由 于 频 
繁 的 GC 导致 运行 缓慢 (通过 spark web ui 可 以 观察 到 作业 的 GC 耗 时 ) ， 意 味 着 task 执行 用 
户 代码 的 内 存 不 够 用 ， 那 么 同样 建议 调 低 参 数 spark. storage. memoryFraction 和 spark. shuffle. 
memoryFraction 的 值 。 

UnifiedMemoryManager 模式 下 ， 整 个 堆 空 间 分 为 Spark Memory 和 User Memory， 在 Spark 
Memory 内 部 又 分 为 Storage Memory 和 Execution Memory ，Storage Memory 和 Execution Memory 
并 没有 硬 界 限 ， 可 以 相互 借用 空间 。 可 以 通过 参数 spark. memory. fraction (默认 为 0.75) 来 
设置 Spark Memory 所 占 的 整个 堆 空 间 的 比例 ， 剩 下 的 空间 就 是 User Memory (默认 为 
1 -0.75 =0.25); 通过 spark. memory. storageFraction (默认 为 0.5) 设置 Storage Memory 所 占 
的 Spark Memory 的 比例 。 根 据 实 际 程序 中 Cache 的 多 少 、Shuffle 的 多 少 和 对 象 的 多 少 等 ， 可 
以 调整 上 述 各 个 参数 来 调整 各 个 内 存 区 的 大 小 ， 进 而 优化 程序 。 

下 面 重点 介绍 UnifiedMemoryManager 模式 下 的 相 关 人 参数 。 

1) spark. storage. memoryFraction。 人 参数 说 明 : 该 参数 用 于 设置 RDD 持久 化 数据 在 Exec- 
utor 内 存 中 所 占 的 比例 ， 默 认为 0.6。 也 就 是 说 ， 默 认 Executor 60% 的 内 存 ， 可 以 用 来 保存 
持久 化 的 RDD 数据 。 根 据 不 同 的 持久 化 策略 ， 如 果 内 存 不 够 时 ， 可 能 数据 就 不 会 持久 化 ， 
或 者 数据 会 写 人 磁盘 。 人 参数 调 优 建议 : 如果 Spark 作业 中 有 较 多 的 RDD 持久 化 操作 ， 该 参 
数 的 值 可 以 适当 提高 一 些 ， 保 证 持久 化 的 数据 能 够 容纳 在 内 存 中 ， 避 免 内 存 不 够 缓存 所 有 的 
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数据 ， 导 致 数据 只 能 写 人 磁盘 中 ， 降 低 了 性 能 。 但 是 如 果 Spark 作业 中 的 Shuffle 类 操作 比较 
多 ， 而 持久 化 操作 比较 少 ,那么 这 个 参数 的 值 适当 降低 一 些 比较 合适 。 此 外 ， 如 果 发 现 作 业 
由 于 频繁 的 GC 导致 运行 缓慢 (通过 Spark web UI 可 以 观察 到 作业 的 GC 耗 时 ) ， 意 味 着 task 
执行 用 户 代码 的 内 存 不 够 用 ， 那 么 同样 建议 调 低 这 个 参数 的 值 。 

2) spark. shuffle. memoryFraction。 参 数 说 明 : 该 参数 用 于 设置 Shuffle 过 程 中 一 个 Task 
拉 取 到 上 个 Stage 的 Task 的 输出 后 》 进行 聚合 操作 时 能 够 使 用 的 Executor 内 存 的 比例 ， 默认 
为 0.2。 也 就 是 说 ，Executor 默认 只 有 20% 的 内 存 用 来 进行 该 操作 。Shuffle 操作 在 进行 聚合 
时 ， 如 果 发 现 使 用 的 内 存 超出 了 这 个 20% 的 限制 ， 那么 多 余 的 数据 就 会 溢 写 到 磁盘 文件 中 
去 ， 此 时 就 会 极 大 地 降低 性 能 。 参 数 调 优 建 议 ， 当 Spark 作业 中 的 RDD 持久 化 操作 较 少 、 
Shuffle 操作 较 多 时 ， 建 议 降 低 持久 化 操作 的 内 存 占 比 ， 提 高 Shuffle 操作 的 内 存 占 比比 例 ， 
避免 Shuffle 过 程 中 数据 过 多 时 内 存 不 够 用 ， 必 须 溢 写 到 磁盘 上 ， 从 而 降低 了 性 能 。 此 外 ， 
如 果 发 现 作业 由 于 频繁 的 GC 导致 运行 缓慢 ， 意 味 着 Task 执行 用 户 代 码 的 内 存 不 够 用 ， 那 
么 同样 建议 调 低 这 个 参数 的 值 。 

2. 确定 内 存 消耗 

可 以 在 程序 中 通过 Cache 方法 将 RDD Cache 到 内 存 中 ， 然 后 通过 WebUI 的 Storage 页 面 
查看 该 RDD 占用 了 多 少 内 存 ， 或 查看 Driver 的 日 志 。 

有 很 多 工具 也 可 以 帮助 用 户 了 解 内 存 的 消耗 ， 比 如 JVM 自 带 的 内 存 消耗 诊断 工具 ， 如 
JMap、JSonsole 等 ; 第 三 方 工具 如 IBM JVM Profile Tools 等 。 
通过 这 些 方法 ， 可 以 了 解 各 种 数据 结构 、 广 播 变 量 等 对 内 存 的 占用 ， 从 而 选择 使 用 对 内 
存 更 为 友好 的 数据 结构 。 

3. 数据 结构 调 优 

详情 请 参阅 9. 3. 1 节 的 “准则 八 : 使 用 优化 的 数据 结构 ”。 

4. 序列 化 要 持久 化 的 RDD 

详情 请 参阅 9. 3.4 节 。 

5. 垃圾 回收 的 调 优 

由 于 Spazk 运行 在 JVM 平台 上 ， 而 垃圾 回收 是 JVM 的 “ 死 六 ”， 所 以 内 存 的 调 优 肯定 离 
不 开 垃 圾 回收 的 优化 ， 更 详细 的 信息 请 参考 9. 3. 9 节 。 


六 


有 时 在 开发 过 程 中 ,会 遇 到 需要 在 算 子 函数 中 使 用 外 部 大 变量 的 场景 (如 100 MB 的 大 
集合 ) ， 那 么 此 时 就 可 以 考虑 使 用 Spark 的 广播 (Broadcast) 功能 来 提升 性 能 。 

Spark 使 用 了 Shared - Nothing 架构 ， 数 据 以 分 区 的 形式 散落 在 各 个 结 点 上 ， 每 个 结 点 都 
有 自己 的 CPU 、 内 存 和 存储 资源 。tasks 并 没有 共享 的 全 局 内 存 区 域 ，Driver 和 Task 通过 通 
信 来 共享 数据 。 比 如 ， 当 一 个 RDD 算 子 所 使 用 的 函数 中 引用 了 一 个 来 自 Driver 的 变量 时 ， 
Spark 会 将 该 变量 的 一 个 副本 随 一 个 Task 一 起 发 送 给 Executors ， 然 后 每 个 Task 得 到 一 个 该 
变量 的 副本 ， 并 以 只 读 的 形式 访问 它 ， 任 何 对 该 变量 的 修改 都 是 本 地 的 ， 并 不 会 返回 给 
Driver。 这 个 发 送 动作 在 每 个 Stage 的 开始 都 会 发 生 一 次 。 

这 种 默认 的 行为 在 Driver 和 Task 共享 较 大 的 变量 (如 静态 查询 表 ) ， 且 Job 有 多 个 Stage 
时 并 不 高 效 ， 比 如 该 静态 查询 表 的 大 小 是 100 MB 且 该 Job 有 10 个 Stage， 则 Spark 会 将 这 
100 MB 的 数据 发 送 给 每 个 Executor 共 10 次 。 大 量 的 变量 副本 在 网 络 中 传输 的 性 能 开销 ， 以 
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及 在 各 个 结 点 的 Executor 中 占用 过 多 内 存 导 致 的 频繁 CC， 都 会 极 大 地 影响 性 能 。 这 显然 并 
不 高 效 ，Spark 为 此 推出 了 广播 变量 。 

Spark 的 广播 变量 只 会 发 送 给 Executor 结 点 一 次 ， 且 发 送 后 广播 变量 会 以 非 序列 化 的 形 
式 保存 在 Executor 内 存 中 ， 而 不 会 为 每 个 Task 都 发 送 一 份 。Spark 还 会 使 用 高 效 的 广播 算法 O) 
(Http 或 Torrent 方 式 ) 来 分 发 变量 ， 所 以 网 络 通信 的 开销 并 不 大 。 熟 悉 源 代码 的 朋友 都 知 
道 ， 在 Spark 的 HadoopRDD 中 ， 就 采用 了 广播 来 进行 Hadoop 的 JobConf 的 传输 以 提高 效率 。 
广播 后 的 变量 会 保证 每 个 Executor 的 内 存 中 只 驻 留 一 份 该 变量 的 副本 ， 而 Executor 中 的 task 
执行 时 共享 该 Executor 中 的 那 份 变量 副本 。 这 样 的 话 ， 可 以 大 大 减少 变量 副本 的 数量 ， 从 而 
减少 网 络 传输 的 性 能 开销 ， 并 减少 对 Executor 内 存 的 占用 开销 ， 降 低 GC 的 频率 。 

需要 说 明 的 是 ， 由 于 每 个 Stage 的 Task 公用 的 数据 在 Stage 开始 时 都 会 向 每 个 Executor 
结 点 发 送 一 次 ， 发 送 后 这 些 公 用 数据 会 以 序列 化 的 形式 缓存 在 Executor 中 ， 然 后 各 个 任务 在 
运行 时 反 序 列 化 这 些 公用 的 数据 ， 以 获得 一 个 只 读 的 副本 供 自 己 使 用 ， 这 就 意味 着 显 式 创建 
广播 变量 的 模式 ， 只 有 在 Job 有 多 个 Stage， 且 多 个 Stage 的 Task 需要 访问 来 自 Driver 的 相同 
数据 时 ， 或 者 需要 以 非 序 列 化 的 形式 缓存 数据 时 ， 才 真正 有 意义 。 

事实 上 ，Spark 会 在 Master 上 打印 出 每 个 任务 序列 化 后 的 大 小 ， 通 常 来 讲 ， 大 于 20 KB 
的 任务 就 可 以 考虑 是 否 可 以 通过 广播 机 制 进行 优化 。 

可 以 通过 在 一 个 只 读 变 量 v 上 调用 SparkContext. broadcast(v) 来 创建 广播 变量 ,广播 变 
量 本 质 上 是 围绕 着 变量 v 的 封装 ， 广 播 后 可 以 通过 value 方法 访问 这 个 广播 变量 的 值 。 在 创 
建 了 广播 变量 之 后 ， 在 集群 上 的 所 有 函数 中 都 应 该 使 用 它 来 蔡 代 使 用 v， 这样 v 就 不 会 不 止 
一 次 地 在 结 点 之 间 传 输 了 。 另 外 ， 为 了 确保 所 有 的 结 点 获得 相同 的 变量 ， 变 量 v 在 被 广播 之 
后 就 不 应 该 再 修改 。 

实例 代码 如 下 。 






































































































































// 以 下 代码 在 算 子 函数 中 使 用 了 外 部 的 变量 

// 此 时 没有 做 任何 特殊 操作 ,每 个 Stage 开始 时 都 会 向 每 个 Executor 结 点 发 送 一 次 该 变量 

全 三 

rddl. map( V...) 

// 以 下 代码 将 V 封装 成 了 Broadcast 类 型 的 广播 变量 

// 在 算 子 函数 中 ,使 用 广播 变量 时 ,首先 会 判断 当前 Task 所 在 的 Executor 内 存 中 是 否 有 变 

量 副本 。 如 果 有 则 直接 使 用 ;如 果 没 有 则 从 Driver 或 者 其 他 Executor 结 点 上 远程 拉 取 一 
份 放 到 本 地 Executor 内 存 中 ,每 个 Executor 内 存 中 只 会 驻 留 一 份 广 播 变量 副本 

Wa 

8. valV Broadcast = sc. broadcast( V) 

9. rddl. map(V Broadcast. value...) 


另外 一 个 使 用 广播 变量 的 常用 场景 是 ， 当 对 两 个 表 进 行 Join 操作 时 ， 为 了 避免 Shuffle， 
经 常 将 较 小 的 表 广 播 到 Executor 上 。 
于 持久 化 与 checkpoint 


因为 Spark 程序 执行 的 特性 ， 即 延迟 执行 和 基于 Lineage 最 大 化 的 pipeline ， 当 Spark 中 
由 于 对 某 个 RDD 的 Action 操作 触发 了 作业 时 ， 会 基于 Lineage 从 后 往 前 推 ， 找 到 该 RDD 的 
源头 RDD， 然 后 从 前 往 后 计算 出 结果 。 很 明显 ， 如 果 对 某 个 RDD 执行 了 多 次 Transformation 
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内 核 机 制 解析 及 性 能 调 优 


和 Action 操作 ， 每 次 Action 操作 触发 了 作业 时 都 会 重新 从 源头 RDD 处 计算 一 遍 来 获得 该 
RDD， 然 后 再 对 这 个 RDD 执行 相应 的 操作 。 当 RDD 本 身 计算 特别 复杂 和 耗 时 〈 如 茶 个 计算 


时 长 超过 半 个 小 时 ) 时 ， 这 种 方式 的 性 能 显然 是 很 差 的 ， 此 时 必须 考虑 对 计算 结果 的 数据 
进行 持久 化 。 

持久 化 就 是 将 计算 出 来 的 RDD 根据 配置 的 持久 化 级 别 ， 保 存 到 内 存 或 磁盘 中 ， 以 后 每 
次 对 该 RDD 进行 算 子 操作 时 ， 都 会 直接 从 内 存 或 磁盘 中 提取 持久 化 的 RDD 数据 ， 然 后 执行 
算 子 ， 而 不 会 从 源头 处 重新 计算 一 遍 这 个 RDD， 再 执行 算 子 操作 ， 这 无 疑 会 提高 程序 执行 
的 效率 。 

建议 对 多 次 使 用 的 RDD， 计 算 特 别 复杂 和 耗 时 ， 或 计算 链条 特别 长 的 RDD ， 进 行 持久 
化 。 只 需要 对 希望 缓存 的 RDD Persist 或 Cache 方法 进行 标记 ， 这 两 种 方法 的 区 别 在 于 ， 
Cache 是 将 RDD 持久 化 到 内 存 里 ， 而 Persist 可 以 指定 不 同 的 持久 化 级 别 。 在 标记 之 后 ， 当 
由 Action 触发 Job 导致 了 该 RDD 的 计算 后 ,计算 结果 就 会 根据 指定 的 持久 化 级 别 被 持久 化 
到 内 存 或 磁盘 中 。 

RDD 的 各 个 持久 化 级 别 如 表 9-1 所 示 。 

表 9-1 RDD 的 持久 化 级 别 
持久 化 级 别 含义 解释 

使 用 未 序列 化 的 Java 对 象 格式 ， 将 数据 保存 在 内 存 中 。 如 果 内 存 不 够 存放 所 有 
的 数据 ， 则 数据 就 可 能 有 部 分 不 会 进行 持久 化 。 那 么 下 次 对 这 个 RDD 执行 算 子 操 


作 时 ， 那 些 没 有 被 持久 化 的 数据 需要 从 源头 处 重新 计算 一 遍 。 这 是 默认 的 持久 化 
策略 ， 使 用 cache( ) 方 法 时 ， 实 际 使 用 的 就 是 这 种 持久 化 策略 


























MEMORY_ONLY 


















































使 用 未 序列 化 的 Java 对 象 格 式 ， 优 先 尝试 将 数据 保存 在 内 存 中 。 如 果 内 存 不 够 
MEMORY_AND_DISK 存放 所 有 的 数据 ， 会 将 数据 写 人 磁盘 文件 中 ， 下 次 对 这 个 RDD 执行 算 子 时 ， 持 久 
化 在 内 存 和 磁盘 文件 中 的 数据 会 被 读 取 出 来 使 









































基本 含义 同 MEMORY_ONLY。 唯 一 的 区 别 是 ， 会 将 RDD 中 的 数据 进行 序列 化 ， 
MEMORY_ONLY_SER RDD 的 每 个 partition 会 被 序列 化 成 一 个 字 节 数组 。 这 种 方式 更 加 节省 内 存 ， 从 而 
可 以 避免 持久 化 的 数据 占用 过 多 内 存 导致 频繁 GC 

















基本 含义 同 MEMORY_AND_DISK。 唯 一 的 区 别 是 ， 会 将 RDD 中 的 数据 进行 序 














MEMORY_AND_DISK_SER 列 化 ，RDD 的 每 个 partition 会 被 序列 化 成 一 个 字 节 数组 。 这 种 方式 更 加 节省 内 存 ， 
从 而 可 以 避免 持久 化 的 数据 占用 过 多 内 存 导致 频繁 GC 
DISK_ONLY 使 用 未 序列 化 的 Java 对 象 格式 ， 将 数据 全 部 写 人 磁盘 文件 中 











将 RDD 以 序列 化 的 方式 存储 在 Alluxio 中 ( 曾 用 名 Tachyon) ， 而 不 是 Executor 的 
内 存 中 , 减少 了 垃圾 回收 的 压力 
OFF_HEAP 当 RDD 存储 在 Alluxio 上 时 ，Executors 的 崩溃 不 会 造成 RDD 数据 的 丢失 
事实 上 ，Alluxio 带 来 的 不 止 这 些 ， 它 是 一 套 基于 内 存 的 分 布 式 文件 存储 系统 ， 
为 跨 程序 、 跨 框架 地 共享 内 存 数据 提供 了 一 套 方案 
































MEMORY_ONLY_ 2， 
MEMORY_ONLY_SER_2, 
MEMORY_AND_DISK 2,， 
MEMORY_AND_DISK_SER_2, 
DISK_ONLY_2 ， 

等 等 . 


对 于 上 述 任意 一 种 持久 化 策略 ， 如 果 加 上 后 缀 _ 2， 代 表 的 是 将 每 个 持久 化 的 数 
据 都 复制 一 份 副本 ， 并 将 副本 保存 到 其 他 结 点 上 。 这 种 基于 副本 的 持久 化 机 制 主 
要 用 于 进行 容错 。 假 如 某 个 结 点 挂 掉 ， 结 点 的 内 存 或 磁盘 中 的 持久 化 数据 丢失 了 ， 
那么 后 续 对 RDD 计算 时 还 可 以 使 用 该 数据 在 其 他 结 点 上 的 副本 。 如 果 没 有 副本 ， 
就 只 能 将 这 些 数 据 从 源头 处 重新 计算 一 遍 了 





















































Spark 提供 了 不 同 的 持久 化 级 别 ， 以 满足 内 存 使 用 率 和 CPU 效率 的 均衡 。 如 何 选择 合适 
的 持久 化 级 别 呢 ? 
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通常 遵循 的 准则 是 ， 优 先 考 虑 内 存 ， 内 存放 不 下 就 考虑 序列 化 后 放 在 内 存 里 ， 尽 量 不 要 
存储 到 磁盘 上 ， 因 为 一 般 RDD 的 重新 计算 比 从 磁盘 中 读 取 更 快 ， 只 有 在 需要 更 快 的 恢复 时 
才 使 用 备份 级 别 〈 所 有 的 存储 级 别 都 可 以 通过 重新 计算 来 提供 全 面 的 容错 性 ， 但 是 备份 级 
别人 允许 用 户 继续 在 RDD 的 备份 上 执行 任务 ， 而 无 须 重 新 计算 丢失 的 分 区 ) 。 O) 

按照 顺序 来 讲 ， 通 常 按 照 以 下 方式 来 选择 。 

采用 默认 情况 下 性 能 最 高 的 MEMORY_ONLY。 该 持久 化 级 别 下 ， 不 需要 进行 序列 化 与 
反 序 列 化 操作 ， 就 避免 了 这 部 分 的 性 能 开销 ; 对 这 个 RDD 的 后 续 算 子 操作 ， 都 是 基于 纯 内 
存 中 的 数据 的 操作 ， 不 需要 从 磁盘 文件 中 读 取 数据 ， 性 能 也 很 高 ;而 且 不 需要 复制 一 份 数据 
副本 ， 并 远程 传送 到 其 他 结 点 上 。 但 是 这 里 必须 要 注意 的 是 ， 使 用 该 持久 化 级 别 的 前 提 是 ， 
集群 的 内 存 必 须 足 够 大 ， 可 以 绰绰有余 地 存放 整个 RDD 的 所 有 数据 ， 如 果 RDD 中 的 数据 比 
较 多 (比如 几 十 亿 条 ) ， 直 接 用 这 种 持久 化 级 别 可 能 会 导致 ]VM 的 OOM 内 存 溢出 异常 。 

如 果 使 用 MEMORY_ONLY 级 别 时 发 生 了 内 存 溢出 ， 那 么 建议 尝试 使 用 MEMORY_ONLY 
_SER 级 别 。 该 级 别 会 将 RDD 数据 序列 化 后 再 保存 到 内 存 中 ， 此 时 每 个 partition 仅仅 是 一 个 
字 节 数组 而 已 ， 大 大 减少 了 对 象 数量 ， 并 降低 了 内 存 占用 。 这 种 级 别 比 MEMORY_ONLY 多 
出 来 的 性 能 开销 ， 主 要 就 是 序列 化 与 反 序列 化 的 开销 。 但 是 后 续 算 子 可 以 基于 纯 内 存 进 行 操 
作 ， 因 此 性 能 总 体 还 是 比较 高 的 。 此 外 ， 可 能 发 生 的 问题 同上 ， 如 果 RDD 中 的 数据 量 过 多 ， 
还 是 可 能 会 导致 00M 内 存 溢出 的 异常 。 

如 果 纯 内 存 的 级 别 都 无 法 使 用 ， 那 么 建议 使 用 MEMORY_AND_DISK_SER 策略 ， 而 不 是 
MEMORY_AND_DISK 策略 。 因 为 此 时 RDD 的 数据 量 很 大 ， 内 存 无 法 完全 放下 ， 需 要 通过 序 
列 化 来 节省 内 存 和 磁盘 的 空间 开销 。 该 策略 会 优先 尽量 尝试 将 数据 缓存 到 内 存 中 ， 内 存 缓存 
不 下 时 才 会 写 人 磁盘 。 
通常 不 建议 使 用 DISK_ONLY 级 别 。 因 为 完全 基于 磁盘 文件 进行 数据 的 读 写 ， 会 导致 性 
能 急剧 降低 ， 有 时 还 不 如 重新 计算 一 次 该 RDD。 
通常 不 建议 使 用 后 级 为 2 的 备份 级 别 。 因 为 该 级 别 必须 将 所 有 的 数据 都 复制 一 份 副 本 ， 
并 发 送 到 其 他 结 点 上 ， 而 数据 复制 和 网 络 传输 会 导致 较 大 的 性 能 开销 ， 除 非 是 作业 的 高 可 用 
性 要 求 很 高 ， 否 则 不 建议 使 用 。 

这 里 需要 重点 指出 的 是 ， 推 荐 尝试 使 用 OFF_HEAP 方式 ， 因 为 该 方式 将 RDD 数据 持久 
化 到 了 Alluxio 中 ( 曾 用 名 Tachyon) ， 而 不 是 Executor 的 内 存 中 。OFF_HEAP 方式 有 以 下 几 
个 优势 : 允许 多 个 Executors 共享 同一 个 内 存 池 ; 显著 地 减少 了 垃圾 回收 的 开销 ; 如 果 某 个 
Executors 朋 溃 ， 绥 存 的 数据 不 会 入 失 。 事 实 上，Alluxio 带 来 的 不 止 这 些 ， 它 是 一 套 基于 内 
存 的 分 布 式 文件 存储 系统 ， 为 跨 程 序 、 跨 框架 地 共享 内 存 数据 提供 了 一 套 方案 。 更 详细 的 情 
况 请 查阅 Alluxio 官网 。 

需要 说 明 的 是 ， 持 久 化 会 最 大 化 地 保留 整个 RDD 的 所 有 分 区 数据 ， 但 是 如 果 当 前 的 计 
算 需 要 内 存 空间 而 空闲 内 存 不 够 ,那么 持久 化 在 内 存 中 的 数据 必须 让 出 空间 ， 此 时 如 果 
RDD 的 持久 化 级 别 指定 了 可 以 把 数据 放 在 磁盘 上 ， 那 么 部 分 分 区 数据 就 可 以 从 内 存 转 入 磁 
盘 ， 否 则 数据 就 会 丢失 ; Spark 的 持久 化 也 具有 容错 性 ， 当 持久 化 的 RDD 的 某 一 分 区 丢失 
后 ， 后 续 计 算 该 分 区 后 也 会 自动 重新 计算 并 持久 化 该 分 区 ; 同时，Spark 也 有 自己 的 一 套 机 
制 ， 自 动 监控 每 个 结 点 上 的 缓存 使 用 率 ， 并 通过 LRU (Least Recently Used， 近 期 最 少 使 用 ) 
算法 删除 过 时 的 缓存 数据 (当然 也 可 以 手动 使 用 RDD. unpersist( ) 方法 来 删除 ) 。 也 就 是 说 ， 
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持久 化 的 数据 在 执行 时 不 一 定 被 有 效 地 持久 化 了 ， 要 想 知道 要 持久 化 的 RDD 有 没有 被 正确 
地 持久 化 ， 可 以 通过 查看 WebUI 的 Executor 页 面 ， 详 见 9.2. 8 节 。 
下 面 是 一 个 使 用 Persist 的 示例 。 
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//cache 使 用 示例 : 
val rddl = sc. textFile( " hdfs://master:9000/data/ README. md " ). cache( ) 
rddl. map( ...) 
rddl. reduce( ...) 
// persist( ) 方 法 表示 :手动 选择 持久 化 级 别 , 并 使 用 指定 的 方式 进行 持久 化 
// 例 如 ,StorageLevel. MEMORY_AND_DISK_SER 表示 ,内 存 充足 时 优先 持久 化 到 内 存 中 ,内 
存 不 充足 时 持久 化 到 磁盘 文件 中 。 而 且 其 中 的 _SER 后 缀 表示 使 用 序列 化 的 方式 来 保存 
RDD 数据 ,此 时 RDD 中 的 每 个 partition 都 会 序列 化 成 一 个 大 的 字 节 数组 ,然后 再 持久 化 
到 内 存 或 磁盘 中 。 序 列 化 的 方式 可 以 减少 持久 化 的 数据 对 内 存 /磁盘 的 占用 量 ,进而 避 
免 内 存 被 持久 化 数据 占用 过 多 ,从 而 发 生 频 繁 GC 
// persist 使 用 示例 : 
val rddl = sc. textFile ( " hdfs://master:9000/ data/ README. md " ). persist (StorageLevel MEMORY_ 
AND_DISK_SER) 
rddl. map(...) 
rddl. reduce( ...) 



























































把 数据 通过 Persist 或 Cache 持久 化 到 内 存 或 磁盘 中 ,虽然 是 快速 的 但 却 不 是 最 可 靠 的 ， 
Checkpoint 机 制 的 产生 就 是 为 了 更 加 可 靠 地 持久 化 数据 以 复 用 RDD 计算 数据 ， 通 常 针 对 整 
个 RDD 计算 链条 中 特别 需要 数据 持久 化 的 环节 ， 启 用 Checkpoint 机 制 来 确保 高 容错 和 高 可 


用 性 。 














可 以 通过 调用 SparkContext setCheckpointDir 方法 来 指定 Checkpoint 时 持久 化 的 RDD 的 
数据 的 存放 位 置 。 在 Checkpoint 中 可 以 指定 把 数据 以 多 副本 的 方式 存放 在 本 地 或 HDFS 中 
(在 生产 环境 下 通常 是 放 在 HDFS 中 ， 从 而 天 然 地 借助 HDFS 高 容错 和 高 可 靠 的 特征 完成 最 
大 化 的 可 靠 的 持久 化 ) ; 同时 为 了 提高 效率 ， 可 以 指定 多 个 目录 。 

需要 说 明 的 是 ，Checkpoint 同 Persist 一 样 是 惰性 执行 的 ， 在 对 某 个 RDD 标记 了 需要 
Checkpoint 后 ， 并 不 会 立即 执行 ， 只 有 在 后 续 有 Action 触发 Job 从 而 导致 了 该 RDD 的 计算 ， 
且 在 这 个 Job 执行 完成 后 ， 才 会 从 后 往 前 回溯 找到 标记 了 Checkpoint 的 RDD， 然 后 重新 启动 
一 个 Job 来 执行 具体 的 Checkpoint， 所 以 一 般 都 会 对 需要 进行 Checkpoint 的 RDD 先进 行 Per- 
sist 标记 ， 从 而 把 该 RDD 的 计算 结果 持久 化 到 内 存 或 者 磁盘 上 ， 以 备 checkpoint 复 用 。 

下 面 是 一 个 使 用 Checkpoint 的 示例 。 
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// checkpoint 使 用 示例 : 

// 配 置 CheckpointDir 

sc. setCheckpointDir( " hdfs://master:9000/spark/ checkpoint) 

val rddl = sc. textFile( " hdfs://master:9000/data/ README. md " ). cache( ) 
// 对 rddl 标记 checkpoint 

rddl. checkpoint( ) 

[vaction 触发 了 Job 才能 导致 checkpoint 的 真正 执行 

rddl. count( ) 
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数据 本 地 性 





数据 本 地 性 是 指数 据 与 执行 的 代码 的 远近 程度 。 基 于 数据 与 执行 的 代码 各 自 所 在 的 位 O) 
置 ， 从 近 到 远 的 本 地 性 级 别 依次 如 下 。 

e PROCESS_LOCAL: 数据 与 执行 的 代码 在 同一 个 JVM 内 存 中 ， 数 据 已 经 缓存 到 执行 代 

码 所 在 的 Executor 的 内 存 中 了 ， 即 读 取 缓存 在 本 地 结 点 的 数据 ， 这 是 效率 最 高 的 数据 

本 地 性 级 别 (该 本 地 性 级 别 和 cache 有 关 ) 。 

e NODE_LOCAL: 数据 与 执行 的 代码 在 同一 个 结 点 上 ， 需 要 从 执行 代码 所 在 的 结 点 上 的 

本 地 存储 中 读 取 出 数据 ， 即 读 取 本 地 结 点 硬盘 数据 。 比 如 ， 数 据 在 同一 个 结 点 的 hdfs 

上 ， 或 在 同一 个 结 点 的 另 一 个 Executor 上 。 因 为 数据 需要 在 进程 间 移 动 ， 该 级 别 比 
PROCESS_LOCAL 稍 慢 。 

e NO_PREF: 从 任意 地 方 访问 该 数据 的 速度 都 一 样 ， 没 有 具体 的 位 置 偏好 。 

e RACK_LOCAL: 数据 所 在 的 Server 与 执行 代码 的 Server 在 同一 台 机 架 上 ， 一 般 需 要 通 
过 一 台 交 换 机 在 网 络 上 传输 到 执行 代码 所 在 的 结 点 上 。 

e ANY: 数据 位 于 不 在 同一 台 机 架 的 其 他 集群 的 结 点 上 ， 即 读 取 非 本 地 结 点 数据 。 

数据 本 地 性 对 程序 的 性 能 有 很 大 的 影响 。 如 果 数 据 和 要 执行 的 代码 在 一 起 ， 计 算 速 度 就 
很 快 ; 而 当 它 们 不 在 一 起 时 ， 其 中 一 个 就 必须 移动 到 另 一 个 所 在 的 位 置 ， 而 数据 在 网 络 上 的 
传输 会 导致 大 量 的 延 时 和 开销 ， 毕 竟 磁 盘 IO 和 网 络 IO 都 是 耗 时 的 操作 。 

在 大 数据 处 理 模式 下 ， 一 般 代 码 都 比 数据 小 ， 所 以 序列 化 了 的 代码 的 移动 比 数据 的 移动 
更 快 ， 分布 式 计算 系统 的 精髓 就 在 于 移动 代码 而 非 移动 数据 ， 即 “数据 不 动 代码 动 "。 数 据 
本 地 性 的 原则 就 是 尽量 避免 数据 在 网 络 上 甚至 磁盘 上 的 传输 ， 尽 量 将 计算 移 到 数据 所 在 的 结 
点 上 进行 。Spark 的 调度 机 制 就 是 基于 这 一 准则 来 进行 调度 的 。 

Spark 中 任务 的 处 理 需 要 考虑 数据 本 地 性 的 场合 ， 基 本 上 就 两 种 : 一 是 数据 来 源 于 外 部 
数据 源 (如 HDFS); 二 是 数据 来 源 于 RDD Cache ( 即 由 CacheManager 从 BlockManager 中 读 
取 ， 或 者 Streaming 数据 源 RDD ) 。 其 他 情况 下 ， 不 涉及 Shuffle 操作 的 不 构成 划分 Stage 和 
Task 的 基准 ， 也 就 不 存在 本 地 性 问题 ;而 如 果 是 ShuffleRDD ， 由 于 其 本 地 性 始终 为 No Pre- 
fer， 因 此 其 实 也 不 存在 本 地 性 问题 。 

在 理想 情况 下 ， 任 务 当 然 是 分 配 在 可 以 从 本 地 读 取 数据 的 结 点 上 时 (同一 个 JVM 内 部 
或 同一 台 物 理 机 器 内 部 ) 的 运行 时 性 能 最 佳 。 但 是 每 个 任务 的 执行 速度 无 法 准确 估计 ， 所 
以 很 难 在 事先 获得 全 局 最 优 的 执行 策略 。 当 Spark 应 用 程序 得 到 一 个 计算 资源 时 ， 如 果 没 有 
可 以 满足 最 佳 本 地 性 需求 的 任务 可 以 运行 ， 即 任何 空闲 的 Executor 上 都 没有 尚未 处 理 的 数据 
时 ， 计 算 框架 通常 有 两 种 选择 : 中 一 直 等 待 直到 待 处理 的 数据 所 在 的 结 点 的 CPU 空闲 下 来 ， 
然后 调度 处 理 该 批 数据 的 Task 到 该 结 点 上 ， 这 样 能 更 好 地 匹配 任务 的 本 地 性 ; @ 不 进行 等 
待 ， 直 接 将 处 理 该 批 数 据 的 Task 调度 到 其 他 结 点 上 执行 ， 当 然 此 时 该 批 数据 需要 移动 到 相 
应 的 结 点 上 ， 这 是 退 而 求 其 次 ， 运行 一 个 本 地 性 条 件 稍 差 一 点 的 任务 。 

Spark 所 遵循 的 原则 是 ， 调 度 作 业 时 优先 调度 到 有 最 好 本 地 性 的 结 点 上 去 执行 Task， 当 
较 高 的 数据 本 地 性 级 别 不 能 满足 时 ，Spark 退 而 求 其 次 调度 作业 到 次 好 的 本 地 性 结 点 。 具 体 
实施 时 ，Spark 混合 了 这 两 种 方案 ， 即 会 首先 等 待 一 小 会 儿 以 期 望 忙碌 的 CPU 空闲 下 来 ， 如 
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果 这 个 等 待 的 “一 小 会 儿 ” 到 了 而 CPU 仍然 忙碌 ， 就 会 移动 数据 到 有 空闲 CPU 的 结 点 去 执 


行 。 这 个 需要 等 待 的 “一 小 会 儿 ” 是 可 以 通过 参数 spark. locality. wait 、spark. locality. 
wait. process 、spark. locality. wait node 和 spark. locality. wait. rack 来 配置 的 ， 这 几 个 参数 一 起 
决定 了 Spark 任务 调度 模块 在 得 到 等 分 配 任务 时 ， 如 果 没 有 更 好 的 本 地 性 级 别 ， 和 暂时 不 分 配 
任务 而 是 等 待 一 小 会 儿 以 期 望 获得 更 好 的 本 地 性 级 别 的 等 待 时 间 。 

e spark. locality. wait: 调度 作业 时 ， 如 果 没 有 更 好 的 本 地 性 级 别 ， 退 而 求 其 次 调度 到 次 
好 的 本 地 性 级 别 的 等 待 时 间 ， 默 认 是 3s。 该 时 间 是 所 有 本 地 性 级 别 的 等 待 时 间 
(process -local 、node -local 、rack -local 和 any) 的 默认 值 。 当 然 也 可 以 分 别 配 置 各 
个 本 地 性 级 别 的 等 待 时 间 。 

® spark. locality. wait. process: PROCESS_LOCAL 本 地 性 级 别 的 等 待 时 间 ， 即 尝试 访问 组 
存在 Executor 进程 的 内 存 中 数据 的 等 待 时 间 ， 默 认 值 是 spark. locality. wait 的 值 。 

e spark. locality. wait node: NODE_LOCAL 本 地 性 级 别 的 等 竺 时间， 默认 值 是 spark.， lo- 
cality. wait 的 值 。 比 如 ， 可 以 将 该 值 设置 为 0， 以 跳 过 NODE_LOCAL 本 地 性 级 别 ， 而 
直接 尝试 RACK_LOCAL。 

e spark. locality. wait. rack: RACK_LOCAL 本 地 性 级 别 的 等 待 时 间 ， 默 认 值 是 spark. locality. 
wait 的 值 。 

一 般 来 说 ， 这 几 个 参数 默认 的 配置 均 不 需要 修改 ,但 如 果 Task 执行 时 间 长 且 本 地 性 级 
别 差 (可 以 通过 WebUI 观察 到 ) ， 可 以 调 高 这 些 参数 ， 使 系统 等 待 更 长 的 时 间 ， 以 满足 更 好 
的 本 地 性 来 运行 作业 。 

需要 指出 的 是 ， 在 应 用 程序 刚 启动 ， 处 理 提交 的 第 一 批 任务 时 ， 由 于 当 作业 调度 模块 开 
始 工作 时 ， 有 具体 处 理 任务 的 Executor 可 能 还 没有 完全 注册 完毕 ， 因 此 一 部 分 任务 会 被 错误 地 
放置 到 No Prefer 的 队列 中 ， 由 于 这 部 分 任务 的 优先 级 仅 次 于 数据 本 地 性 满足 Process 级 别 的 
任务 ,它们 就 有 可 能 被 优先 分 配 到 非 本 地 结 点 上 执行 (在 的 确 没有 Executors 在 对 应 的 结 点 
上 运行 ， 或 者 的 确 是 No Prefer 的 任务 (如 shuffleRDD) 的 情况 下 ， 将 任务 放置 到 No Prefer 
的 队列 中 确实 是 比较 优化 的 选择 ,但 是 在 这 种 情况 下 ， 由 于 只 是 这 部 分 Executor 还 没 来 得 及 
注册 上 而 已 ， 这 种 方法 不 是 一 个 好 选择 ) 。 这 种 情况 下 ， 即 使 调 大 这 几 个 参数 的 数值 也 没有 
帮助 。 针 对 这 种 情况 ， Spark 有 一 些 已 经 完成 的 和 正在 进行 中 的 release patch ( 修复 方案 )， 
试图 通过 动态 调整 No Prefer 队列 、 监 控 executors 注册 比例 等 方式 来 给 出 更 加 智能 的 解决 方 
案 。 然 而 ， 也 可 以 根据 自身 集群 的 启动 情况 ， 通 过 在 创建 SparkContext 之 后 ， 主 动 Sleep 几 
秒 的 方式 来 简单 地 解决 这 个 问题 。 


E22 垃圾 回收 调 优 


与 Hadoop 、HBase 生态 圈 的 众多 项 目 等 一 样 ，Spark 的 运行 离 不 开 JVM 的 支持 ， 同 时 由 
于 Spark 立足 于 内 存 计 算 ， 常 常 需要 在 内 存 中 存放 大 量 数据 ， 再 加 上 Spark 同时 支持 批 处 理 
和 流 式 处 理 ， 对 于 程序 吞吐 量 和 延迟 都 有 较 高 要 求 ， 所 以 Spark 对 于 JVM 垃圾 回收 机 制 
(GC) 的 依赖 更 加 突出 。 而 垃圾 回收 是 JVM 的 “ 死 祥 ”， 它 会 影响 程序 的 性 能 甚至 还 会 带 来 
系统 卡 顿 ， 所 以 GC 参数 的 调 优 在 Spark 应 用 实践 中 显得 尤为 重要 。 

首先 需要 获取 一 些 统计 信息 ， 包 括 内 存 回收 的 频率 、 内 存 回收 耗费 的 时 间 等 。 为 了 获取 这 
些 统计 信息 ， 可 以 把 参数 - verbose :gc - XX. + PrintGCDetails - XX: + PrintGCTimeStamps 添加 到 
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环境 变量 SPARK_JAVA_OPTS 中 。 设 置 完成 后 ，Spark 作业 运行 时 ， 可 以 在 日 志 中 看 到 每 一 次 
垃圾 回收 的 详细 情况 。 需 要 注意 的 是 ， 这 些 信 息 保 存在 集群 的 Executors 中 而 不 是 Driver 中 。 
Spark 垃圾 回收 调 优 的 目标 是 确保 只 有 长 时 间 存 活 的 RDD 才 保存 到 老生 代 区 域 ; 同时 ， 
新 生 代 区 域 需要 足够 大 以 保存 生命 周期 比较 短 的 对 象 。 这 样 ， 在 任务 执行 期 间 可 以 避免 执行 O) 
full GC。 下 面 是 一 些 可 能 有 用 的 执行 步骤 。 
通过 收集 GC 信息 检查 内 存 回收 是 否 过 于 频繁 ， 如 果 在 任务 结束 之 前 执行 了 很 多 次 full 
GC ， 则 表明 任务 执行 的 内 存 空 间 不 足 ; 在 打印 的 内 存 回 收 信息 中 ， 如 果 老 生 代 接 近 消 耗 殖 
尽 ， 那么 减少 用 于 缓存 的 内 存 空间 ， 这 可 以 通过 配置 属性 spark. storage. memoryFraction 来 完 
成 ， 通 过 减少 缓存 对 象 来 提高 执行 速度 是 非常 值得 的 ; 如果 有 过 多 的 minor GC 而 不 是 full 
GC， 那 么 为 Eden 分 配 更 大 的 内 存 是 有 益 的 ， 可 以 为 Eden 分 配 大 于 任务 执行 所 需要 的 内 存 
空间 。 如 果 Eden 的 大 小 确定 为 下 ， 那 么 可 以 通过 - Xmn =4/3 x 来 设置 新 生 代 的 大 小 (将 
内 存 扩大 到 4/3 是 考虑 到 survivor 所 需要 的 空间 ) 。 举 一 个 例子 ， 如 果 任 务 从 HDFS 读 取 数 
据 ， 那 么 任务 需要 的 内 存 空间 可 以 从 读 取 的 block 数量 估算 出 来 。 注 意 解压 后 的 bleok 通常 为 
解压 前 的 2 ~ 3 倍 。 所 以 ， 如 果 需 要 同时 执行 3 或 4 个 任务 ，block 的 大 小 为 64 M， 可 以 估算 
出 Eden 的 大 小 为 4x3 x64 MB; 监控 内 存 回收 的 频率 及 消耗 的 时 间 ， 并 修改 相应 的 参数 设置 。 






























































Shuffle 调 优 BS 


在 Spark 程序 中 ，Shuffle 是 性 能 的 最 大 瓶颈 ， 因 为 Shuffle 的 过 程 往往 伴随 着 磁盘 IO 与 
网 络 LO 等 开销 ， 程 序 编写 的 一 个 准则 就 是 “尽量 避免 使 用 需要 Shuffle 的 算 子 ， 且 在 必须 
Shuffle 时 尽量 减少 Shuffle 的 数据 量 ”， 而 在 Shuffle 不 可 避免 时 ， 也 要 尽量 优化 Shuffle 的 方 
方面 面 以 调 优 性 能 。 

这 里 针对 Shffule 过 程 中 的 一 些 主要 参数 ， 详 细 讲 解 各 个 参数 的 功能 、 默 认 值 ， 以 及 基 
于 实践 经 验 给 出 的 调 优 建议 。 更 详细 的 关于 Shuffle 的 解析 ， 请 参阅 本 书 第 7 章 Shuffle 机 制 。 

e spark. shuffle. file. buffer: 该 参数 用 于 设置 shuffle write task 的 BufferedOutputStream 的 
buffer 缓冲 大 小 。 将 数据 写 到 磁盘 文件 之 前 ， 会 先 写 人 Buffer 缓冲 中 ， 待 缓冲 写 满 之 
后 ， 才 会 汶 写 到 磁盘 ， 默 认 值 为 32 KB。 调 优 建议 : 如 果 作 业 可 用 的 内 存 资源 较为 充 
足 ， 可 以 适当 增加 这 个 参数 的 大 小 〈 比 如 128 KB ) ， 从 而 减少 shuffle write 过 程 中 溢 
写 磁盘 文件 的 次 数 ， 也 就 可 以 减少 磁盘 IO 次 数 ， 进 而 提升 性 能 。 
spark. reducer. maxSizeInFlight: 该 参数 用 于 设置 Shuffle Read Task 的 Buffer 缓冲 大 小 ， 
而 这 个 Buffer 缓冲 决定 了 每 次 能 够 拉 取 多 少数 据 ， 默 认 值 为 48 MB 。 调 优 建议 : 如 果 
作业 可 用 的 内 存 资源 较为 充足 ， 可 以 适当 增加 这 个 参数 的 大 小 (如 96 MB) ， 从 而 减 
少 拉 取 数据 的 次 数 ， 也 就 可 以 减少 网 络 传输 的 次 数 ， 进 而 提升 性 能 。 
spark. shuffle. io. maxRetries: shuffle read task 从 shuffle write task 所 在 结 点 拉 取 属于 自 
己 的 数据 时 ， 如 果 因 为 网 络 异 常 导致 拉 取 失败 ， 是 会 自动 进行 重 试 的 ， 该 参数 就 代表 
了 可 以 重 试 的 最 大 次 数 。 如 果 在 指定 次 数 之 内 拉 取 还 是 没有 成 功 ， 就 可 能 会 导致 作业 
执行 失败 。 默 认 值 为 3。 调 优 建议 : 对 于 那些 包含 了 特别 耗 时 的 Shuffle 操作 的 作业 ， 
建议 增加 重 试 最 大 次 数 (如 30 次 ) ， 以 避免 由 于 JVM 的 Full GC 或 者 网 络 不 稳定 等 因 
素 导 致 的 数据 拉 取 失败 。 在 实践 中 发 现 ， 对 于 针对 超大 数据 量 ( 数 十 亿 一 上 百 亿 ) 
的 Shuffle 过 程 ， 调 节 该 参数 可 以 大 幅度 提升 稳定 性 。 




































































































































内 核 机 制 解析 及 性 能 调 优 


e spark. shuffle. io. retryWait: 具体 解释 同上 ， 该 参数 代表 了 每 次 重 试 拉 取 数据 的 等 待 间隔 ， 
默认 值 是 5 s。 调 优 建议 : 建议 加 大 间隔 时 长 (如 30 s) ， 以 增加 Shuffle 操作 的 稳定 性 。 


® spark. shuffle. memoryFraction 与 spark. storage. memoryFraction (StaticMemoryManager 模 





式 下 )， 或 spark. memory. fraction 与 spark. memory. storageFraction ( UnifiedMemoryMan- 
ager 模式 下 ) : 详情 参考 9. 3. 3 资源 参数 调 优 一 节 。 
spark. shuffle. manager: 该 参数 用 于 设置 ShuffleManager 的 类 型 。Spark 1.5 以 后 ， 有 3 
个 可 选项 : hash 、sort 和 tungsten - sort。HashShuffleManager 是 Spark 1.2 以 前 的 默认 
选项 ， 但 是 Spark 1.2 及 之 后 的 版 本 默认 都 是 SortShuffleManager。Tungsten - Sort 与 
Sort 类 似 ， 但 是 使 用 了 Tungsten 计划 中 的 堆 外 内 存 管 理 机 制 ， 内 存 使 用 效率 更 高 。 调 
优 建议 : 由 于 SortShuffleManager 默认 会 对 数据 进行 排序 ， 因 此 如 果 用 户 的 业务 逻辑 中 
需要 该 排序 机 制 ， 则 使 用 默认 的 SortShuffleManager 即 可 ; 而 如 果 用 户 的 业务 逻辑 不 需 
要 对 数据 进行 排序 ， 那 么 建议 参考 后 面 的 几 个 参数 调 优 ， 通 过 bypass 机 制 或 优化 的 
HashShuffleManager 来 避免 排序 操作 ， 同 时 提供 较 好 的 磁盘 读 写 性 能 。 这 里 需要 注意 
的 是 ， 随 着 Tungsten — Sort 越 来 越 稳定 ， 可 以 尝试 使 用 Tungsten — Sort。 
spark. shuffle. sort. bypassMergeThreshold : 当 ShuffleManager 为 SortShuffleManager 时 ， 如 
果 Shuffle Read Task 的 数量 小 于 这 个 闽 值 ， 则 Shuffle Write 过 程 中 不 会 进行 排序 操作 ， 
而 是 直接 按照 未 经 优化 的 HashShuffleManager 的 方式 去 写 数据 ,但 是 最 后 会 将 每 个 
Task 产生 的 所 有 临时 磁盘 文件 都 合并 成 一 个 文件 ， 并 会 创建 单独 的 索引 文件 ， 上 默认 
值 是 200。 调 优 建议 : 当 使 用 SortShuffleManager 时 ， 如 果 的 确 不 需要 排序 操作 ， 那 么 
建议 将 这 个 参数 调 大 一 些 ， 大 于 Shuffle Read Task 的 数量 。 那 么 此 时 就 会 自动 启用 
bypass 机 制 ， 此 时 Map 端 就 不 会 进行 排序 了 ， 从 而 减少 了 排序 的 性 能 开销 。 但 是 这 种 
方式 下 依然 会 产生 大 量 的 磁盘 文件 ， 因 此 Shuffle Write 性 能 有 待 提 高 。 
spark. shuffle. consolidateFiles: 如 果 使 用 HashShuffleManager， 该 参数 有 效 。 如 果 设 置 
为 tue， 那 么 就 会 开启 Consolidate 机 制 ， 会 大 幅度 合并 Shuffle Write 的 输出 文件 ,在 
Shuffle Read Task 数量 特别 多 的 情况 下 ， 这 种 方法 可 以 极 大 地 减少 磁盘 IO 开销 ， 提 
升 性 能 。 默 认 值 是 False。 调 优 建议 : 如 果 的 确 不 需要 SortShuffleManager 的 排序 机 制 ， 
那么 除了 使 用 bypass 机 制 外 ， 还 可 以 尝试 将 spark. shffle. manager 参数 手动 指定 为 
hash， 使 用 HashShuffleManager， 同 时 开启 consolidate 机 制 。 
e spark. local. dir: Shuffle 的 Write 阶段 使 用 的 本 地 磁盘 目录 。 当 Shuffle 阶段 磁盘 IO 时 间 过 
长 时 ， 可 以 将 该 参数 设置 为 多 个 IO 速度 快 的 磁盘 ， 通 过 增加 IO 来 优化 Shuffle 性 能 。 
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本 章 首先 讲述 了 Spark 的 配置 机 制 ， 以 帮助 我 们 了 解 如 何 配置 程序 的 运行 参数 ; 然后 讲 
解 了 如 何 进行 性 能 诊断 ， 以 了 解 性 能 状况 找 出 性 能 瓶 天， 最 后 详细 描述 了 各 类 常见 的 性 能 优 
化 的 原理 与 方法 。 需 要 注意 的 是 ， 性 能 调 优 不 是 一 劳 永 逸 的 ， 随 着 集群 状况 和 作业 执行 情况 
的 变化 ， 性 能 的 瓶颈 也 是 变化 的 ， 这 就 需要 我 们 分 析 诊断 动态 变化 的 情况 ， 基 于 对 Spark 内 
核 机 制 的 理解 ， 灵 活动 态 地 调整 ， 来 达到 优化 的 效果 。 
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